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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



MBMS is a point- to -multipoint service in which data is transmitted from a single source entity to multiple recipients. 
Transmitting the same data to multiple recipients allows network resources to be shared. 

The MBMS bearer service offers two modes: 

• Broadcast Mode. 

• Multicast Mode. 

MBMS user services can be built on top of the MBMS bearer service. The present document specifies two delivery 
methods for the MBMS user services: download and streaming. Examples of applications using the download delivery 
method are news and software upgrades. Delivery of live music is an example of an application using the streaming 
delivery method. 

There can be several MBMS user services. The objective of the present document is the definition of a set of media 
codecs, formats and transport/application protocols to enable the deployment of MBMS user services. The present 
document takes into consideration the need to maximize the reuse of components of already specified services like PSS 
and MMS. 
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The present document defines a set of media codecs, formats and transport/application protocols to enable the 
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In this version of the specification, only MBMS download and streaming delivery methods are specified. The present 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply: 

Broadcast session: See 3GPP TS 22.146 [2]. 

Forward Error Correction (FEC): in the context of MBMS, a FEC mechanism is used at the application layer to 
allow MBMS receivers to recover lost SDUs 

FLUTE channel: equivalent to an ALC/LCT channel 

An ALC/LCT channel is defined by the combination of a sender and an address associated with the channel by the 

sender (RFC 3926 [9]). 

Multicast joining: See 3GPP TS 22.146 [2]. 

Multicast session: See 3GPP TS 22.146 [2]. 

Multimedia Broadcast/Multicast Service (MBMS): See 3GPP TS 22.146 [2]. 

MBMS user services: MBMS User Service may use more than one Multimedia Broadcast/Multicast Service (bearer 
service) and more than one Broadcast and/or Multicast session 

NOTE: See 3GPP TS 22.246 [3] . 

MBMS user service discovery/announcement: user service discovery refers to methods for the UE to obtain the list of 
available MBMS user services along with information on the user service and the user service announcement refers to 
methods for the MBMS service provider to make the list of available MBMS user services along with information on 
the user service available to the UE 



ETSI 



3GPP TS 26.346 version 6.0.0 Release 6 



12 



ETSI TS 126 346 V6.0.0 (2005-03) 



MBMS user service initiation: UE mechanisms to setup the reception of MBMS user service data 
The initiation procedure takes place after the discovery of the MBMS user service 

MBMS delivery method: mechanism used by a MBMS user service to deHver content 

An MBMS delivery method uses MBMS bearers in delivering content and may make use of associated procedures. 

MBMS download delivery method: delivery of discrete objects (e.g. files) by means of a MBMS download session 

MBMS streaming delivery method: delivery of continuous media (e.g. real-time video) by means of a MBMS 
streaming session 

MBMS download session: time, protocols and protocol state (i.e. parameters) which define sender and receiver 
configuration for the download of content files 

MBMS streaming session: time, protocols and protocol state (i.e. parameters) which define sender and receiver 
configuration for the streaming of content 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

ALC Asynchronous Layered Coding 

APN Access Point Name 

AVC Advanced Video Coding 

BM-SC Broadcast-Multicast - Service Centre 

CC Congestion Control 

ERT Expected Residual Time 

ESI Encoding Symbol ID 

FDT File Delivery Table 

FEC Forward Error Correction 

FLUTE File deLivery over Unidirectional Transport 

GGSN Gateway GPRS Serving Node 

GPRS General Packet Radio Service 

IP Internet Protocol 

LCT Layered Coding Transport 

MBMS Multimedia Broadcast/Multicast Service 

MIME Multipurpose Internet Mail Extensions 

MS Mobile Station 

MSK MBMS Service Key 

MTK MBMS Traffic Key 

MUK MBMS User Key 

PSS Packet Switch Streaming 

PTM Point To Multipoint 

PTP Point To Point 

RTP Real-Time transport Protocol 

SBN Source Block Number 

SCT Sender Current Time 

SDP Session Description Protocol 

TMGI Temporary Mobile Group Identity 

TOI Transport Object Identifier 

TSI Transport Session Identifier 

UDP User Datagram Protocol 

UE User Equipment 

URI Uniform Resource Identifier 

URL Uniform Resource Locator 

XML extensible Markup Language 
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4 MBMS system description 

4.1 IVIBMS functional layers 

Delivering MBMS-based services 3 distinct functional layers are identified - Bearers, Delivery method and User 
service. Figure 1 depicts these layers with examples of bearer types, delivery methods and applications. 
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Bearers: Bearers provide the mechanism by which IP data is transported. IVIBIVIS bearers as defined in 

3GPP TS 23.246 [4] and 3GPP TS 22.146 [3] are used to transport multicast and broadcast traffic 
in an efficient one-to-many manner and are the foundation of IVIBMS-based services. MBMS 
bearers may be used jointly with unicast PDP contexts in offering complete service capabilities. 

Delivery Method: When delivering MBMS content to a receiving application one or more delivery methods are used. 
The delivery layer provides functionality such as security and key distribution, reliability control by 
means of forward-error-correction techniques and associated delivery procedures such as file- 
repair, delivery verification. Two delivery methods are defined, namely download and streaming. 
Delivery methods may be added beyond release 6. Delivery methods may use MBMS bearers 
and may make use of point-to-point bearers through a set of MBMS associated procedures. 

User service: The MBMS User service enables applications. Different application impose different requirements 
when delivering content to MBMS subscribers and may use different MBMS delivery methods. As 
an example a messaging application such as MMS would use the download delivery method 
while a streaming application such as PSS would use the streaming delivery method. 

Figure 1 : Functional Layers for MBMS User Service 



4.2 



MBMS User Service Entities 



Figure 2 shows the MBMS user service entities and their inter-relations. Relation cardinality is depicted as well. 
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Figure 2: Entities and Relations 

An MBMS user service is an entity that is used in presenting a complete service offering to the end-user and allowing 
him to activate or deactivate the service. It is typically associated with short descriptive material presented to the end- 
user, which would potentially be used by the user to decide whether and when to activate the offered service. 

A single service entity can contain multiple distinct multimedia objects or streams, which may need to be provided over 
various MBMS download or MBMS streaming sessions. A download session or a streaming session is associated with 
its MBMS bearers and a set of delivery method parameters specifying how content is to be received on the mobile side. 

A set of one or more MBMS bearers can be used for delivering data as part of an MBMS download or streaming 
session. As an example, the audio and visual part of video stream can be carried on separate MBMS bearers. 
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An MBMS bearer (identified by IP group address and APN) might be used in providing data to more than one MBMS 
download or streaming session (3GPP TS 22.246 [3], clause 5). 

4.3 MBMS bearer service architecture 

The MBMS Bearer Service Architecture is defined in 3GPP TS 23.246 [4]. The MBMS User Service interfaces to the 
MBMS system via 3 entities. 

• The BM-SC. 

• The GGSN. 

• The UE. 

The BM-SC provides functions for MBMS user service provisioning and delivery to the content provider. It can also 
serve as an entry point for IP MBMS data traffic from the MBMS User Service source. 

The GGSN serves as an entry point for IP multicast traffic as MBMS data from the BM-SC. 

4.4 Functional Entities to support MBMS User Services 

Figure 3 depicts the MBMS network architecture showing MBMS related entities involved in providing MBMS user 
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Figure 3: MBMS network architecture model 

MBMS User Service architecture is based on an MBMS receiver on the UE side and a BM-SC on the network side. 

The use of the Gmb and Gi interface in providing IP multicast traffic and managing MBMS bearer sessions is described 
in detailed in 3GPP TS 23.246 [4]. 

Details about the BM-SC functional entities are given in figure 4. 
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Figure 4: BM-SC sub-functional structure 

The Session and Transmission function is further subdivided into the MBMS Dehvery functions and the Associated 
Dehvery functions. 

The BM-SC and UE may exchange service and content related information either over point-to-point bearers or MBMS 
bearers whichever is suitable. To that end the following MBMS procedures are provided: 

• User Service Discovery / Announcement providing service description material to be presented to the end-user 
as well as application parameters used in providing service content to the end-user. 

• MBMS-based delivery of data/content (optionally confidentiality and/or integrity protected) from the BM-SC to 
the UE over IP multicast. 

• Key Request and Registration procedure for receiving keys and key updates. 

• Key distribution procedures whereby the BM-SC distributes key material required to access service data and 
delivered content. 

• Associated Delivery functions are invoked by the UE in relation to the MBMS data transmission. The following 
associated delivery functions are available: 

File repair for download delivery method used to complement missing data. 

Delivery verification and reception statistics collection procedures. 

The interfaces between internal BM-SC functions are outside the scope of the present document. 

A "Proxy and Transport function" may be located between the "Session and Transmission Function" and the GGSN. 
The "Proxy and Transport function" is transparent to the "Session and Transmission function". 
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4.4.1 Content Provider / Multicast Broadcast Source 

The Content Provider/Multicast Broadcast Source may provide discrete and continuous media, as well as service 
descriptions and control data, to the BM-SC to offer services via MBMS broadcast- and multicast bearer services at a 
time. An MBMS User Service may use one or several MBMS delivery methods simultaneously. The Content 
Provider/Multicast Broadcast Source may also be a 3'^'^ Party Content Provider/Multicast Broadcast Source. 

The Content Provider/Multicast Broadcast Source function may reside within the operator's network or may be 
provided from outside the operator's network. The Content Provider/Multicast Broadcast Source can also configure the 
Session and Transmission functions (e.g. delivery or associated delivery). The interface between the Content 
Provider/Multicast Broadcast Source and the BM-SC is outside the scope of the present document. 

4.4.2 MBMS Key Management Function 

The MBMS Key Management function is used for distributing MBMS keys (Key Distribution subfunction) to 
authorized UEs. Before the UE can receive MBMS keys, the UE needs to register to the Key Request subfunction of the 
Key Management function by indicating the MBMS User Service Id. Once registered, the UE can request missing 
MBMS keys to the BM-SC by indicating the specific MBMS key id. In order for the UE to stop the BM-SC to send 
MBMS key updates a deregistration with the MBMS User Service Id is needed. 

If the MBMS User Service does not require any MBMS data protection, then the UE shall not register for key 
management purposes. 

A detailed description of all key management procedures is provided in 3GPP TS 33.246 [20]. 

4.4.3 MBMS Session and Transmission Function 

The MBMS Session and Transmission function transfers the actual MBMS session data to the group of MBMS UEs. 
The MBMS Session and Transmission function interacts with the GGSN through the Gmb Proxy function to activate 
and release the MBMS transmission resources. 

The function contains the MBMS delivery methods, which use the MBMS bearer service for distribution of content. 
Further this function contains a set of Associated-Delivery Functions, which may be invoked by the UE in relation to 
the MBMS data transmission (e.g. after the MBMS data transmission). 

The BM-SC Session and Transmission function is further described in later clauses of the present document as well as 
in3GPPTS23.246[4]. 

MBMS user services data may be integrity and/or confidentiality protected as specified within 3GPP TS 33.246 [20], 
and protection is applied between the BM-SC and the UE. This data protection is based on symmetric keys, which are 
shared between the BM-SC and the UEs accessing the service. 

4.4.4 User Service Discovery / Announcement function 

The User Service Discovery / Announcement provides service description information, which may be delivered via the 
Session and Transmission function or via the Interactive Announcement function. This includes information, which is 
necessary to initiate an MBMS user service as described in clause 5.3.1. Metadata for the service descriptions are 
described in clause 5.2. 

4.4.5 Interactive Announcement Function 

An Interactive Announcement Function may offer an alternative means to provide service descriptions to the UE using 
HTTP or be distributed through other interactive transport methods. 
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4.4.6 MBMS UE 

The MBMS UE hosts the MBMS User Services receiver function. The MBMS receiver function may receive data from 
several MBMS User Services simultaneously. According to the MBMS UE capabilities, some MBMS UEs may be able 
to receive data, belonging to one MBMS User Service from several MBMS Bearer Services simultaneously. The 
MBMS receiver function uses interactive bearers for user service initiation / termination, user service discovery and 
associated delivery procedures. 

In case the MBMS user service is secured, the UE needs one or more cryptographic MBMS service keys, therefore the 
UE requests the relevant cryptographic MBMS service keys using the MBMS registration function by requesting keys. 
The received keys are then used for securing the MBMS session related to the received MSK. 

4.5 Usage of identity of IVIBIVIS session 

NOTE: The specification of usage of identity of MBMS session was agreed at 3GPP SA4#34 but is pending 
specification text. 



5 Procedures and protocol 

This clause defines the procedures and protocols that the MBMS User Services uses. 

5.1 Introduction 

This clause specifies the MBMS User service procedures and protocols. 

5.2 User Service Discovery/Announcement 

5.2.1 Introduction 

User service discovery refers to methods for the UE to obtain a list of available MBMS user services along with 
information on the user services. Part of the information may be presented to the user to enable service selection. 

User service announcement refers to methods for the MBMS service provider to announce the list of available MBMS 
user services, along with information on the user service, to the UE. 

In order for the user to be able to initiate a particular service, the UE needs certain metadata information. The required 
metadata information is described in clause 5.2.2. 

According to 3GPP TS 23.246 [4], in order for this information to be available to the UE operators/service providers 
may consider several service discovery mechanisms. User service announcement may be performed over a MBMS 
bearer or via other means. The download delivery method is used for the user service announcement over a MBMS 
bearer. The user service announcement mechanism based on the download delivery method is described in clause 5.2.3. 
Other user service announcement and discovery mechanisms by other means than the download delivery method are out 
of scope of the present document. 

5.2.2 IVIBIVIS User Service Description metadata fragments 

MBMS User Service Discovery/ Announcement is needed in order to advertise MBMS Streaming and MBMS 
Download User Services in advance of, and potentially during, the User Service sessions described. The User Services 
are described by metadata (objects/files) delivered using the download delivery method as defined in clause 7 or using 
interactive announcement functions. 

MBMS User Service Discovery /Announcement involves the delivery of fragments of metadata to many receivers in a 
suitable manner. The metadata itself describes details of services. A metadata fragment is a single uniquely identifiable 
block of metadata. An obvious example of a metadata fragment would be a single SDP file (RFC 2327 [14]). 
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The metadata consists of: 

• a metadata fragment object describing details of MBMS user services; 

• a metadata fragment object(s) describing details of MBMS user service sessions; 

• a metadata fragment object(s) describing details of Associated delivery methods; 

• a metadata fragment object(s) describing details of service protection. 
Metadata management information consists of: 

• - a metadata envelope object(s) allowing the identification, versioning, update and temporal validity of a 
metadata fragment. 

The metadata envelope and metadata fragment objects are transported as file objects in the same download session 
either as separate referencing files or as a single embedding file - see clause 5.2.3.6). A single metadata envelope shall 
describe a single metadata fragment, and thus instances of the two are paired. An service announcement sender shall 
make a metadata envelope instance available for each metadata fragment instance. The creation and use of both an 
embedded envelope instance and a referenced envelope instance for a particular fragment instance is not recommended. 

The metadata envelope and metadata fragment objects may be compressed using the generic GZip algorithm 
RFC 1952 [42] as content/transport encoding for transmission. Where used over an MBMS bearer, this shall be 
according to Download delivery content encoding using FLUTE - see clause 7.2.5. 

NOTE 1 : It was agreed in principle at S A4#34 that MBMS user service description allows the association of 
delivery methods to one or more access systems. The specification text is FFS 



Service 
Description 



"^ 







1..N 


1 

o 








references 


Delivery 
Method 


references 








1..N 


1..N 






1 


, 0..1 




o 

CD 


1..N 

r 1 




0..1 , 


' 


Associated 










Delivery 


0..1 


1..N 


Session 


1..N 


0..1 


Security 


Proc 
Desc 


adure 
ription 






Desc 


ription 






Desc 


'iption 



Figure 5: Simple Description Data Model 

Figure 5 illustrates the simple data model relation between these description instances using UML [21] for a single User 
Service Description. 

NOTE 2: "N" means any number in each instance. 

One MBMS User Service Description instance shall include at least one delivery method description instance. The 
delivery method description shall refer to one session description instance. 

The delivery method description may contain references to a service protection description and an associated delivery 
procedure description. Several delivery methods may reference the same service protection description, in case the same 
encryption keys are used across delivery methods. 

If the associated delivery procedure description is present in the user service description instance, it may be referenced 
by one or more delivery methods. 
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If the service protection description is present in the user service description instance, it may be referenced by one or 
more delivery methods. 

Multipart MIME may be used to concatenate the descriptions one file for transport. 

5.2.2.1 Session Description 

One or more session descriptions are contained in one session description object. The session description instance shall 
be formatted according to the Session Description Protocol (SDP). Each session description instance must describe 
either one Streaming session or one FLUTE Download session. A session description for a Streaming session may 
include multiple media descriptions for RTF sessions. The sessionDescriptionURI references the session description 
object. The session description is specified in clause 7.3 for the MBMS download delivery method and in clause 8.3 for 
the MBMS streaming delivery method. 

5.2.2.2 Associated Delivery Procedure Description 

The description and configuration of associated delivery procedures is specified in clause 9. The 
associatedProcedureDescriptionURI references, the associated delivery procedure instance. 

An associated delivery procedure description may be delivered on a dedicated announcement channel and updated on a 
dedicated announcement channel as well as in-band with an MBMS download session. 

If an associated delivery procedure description for File-Repair operations is available, then the MBMS receiver may use 
the file repair service as specified in clause 9.3. 

If an associated delivery procedure description for reception reporting is available, then the MBMS receiver shall 
provide reception reports as specified in clause 9.4. 

5.2.2.3 Service Protection Description 

The security description fragment contains the key identifiers and procedure descriptions for one delivery method. 
When different delivery methods use the same security description, the same security description document is 
referenced from the different delivery method elements. 

The security description is reference by the protectionDescriptionURI of the deliveryMethod element. The security 
description fragment shall use the MIME type application/mbms-protection-description. 

The security description contains key identifiers and the server address to request the actual key material. The key 
management servers are protected against overload situations like the associated delivery procedures. Associated 
delivery procedures are defined in clause 9.4. 

The root element of the security description is the securityDescription element. It contains the key identities, which are 
required for one delivery method. Further the security description contains one or more key management server 
addresses (i.e. BM-SC). 

The keyManagement element defines the list of key management servers (i.e. BM-SC). The MBMS UE must register 
with the key management server to receive key material. 

The key management server is protected like the associated delivery procedures against overload conditions. The key 
management server shall be selected as defined in clause 9.3.3. The back-off time shall be determined as defined in 
clause 9.3.2. 

The attribute confidentialityProtection defines whether a confidentiality protection scheme is use. 

The attribute integrityProtection defines whether an integrity protection scheme is use. 

The attribute uiccKeyManagement defines the UICC key management in the MBMS. 
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The element keyld contain the key identifications and the mapping to RTP media flows or FLUTE channels sessions. 
The identity element identifies the key as defined in clause 6.3.2.1 of 3GPP TS 33.246 [20]. The mediaFlow attribute 
specifies the RTP media flow or FLUTE channel. The value shall be of form <IP-destination-address>:<destination- 
port>. The mediaFlow element shall be present when more than one RTP media flow or FLUTE channel is defined in 
one session description element as defined in clause 5.2.2.1. When only one RTP media flow or one FLUTE channel is 
defined is the session description, then the mediaFlow attribute may not be present. The delivery method element 
defines the mapping between the RTP media flow or the FLUTE channel and the key identification. 

XML schema for Security Description: 

<?xml version="l . 0" encoding="UTF-8 " ?> 
<xs ; schema elementFormDefault="qualif ied" 

targetNamespace="urn: 3gpp: metadata: 2004 : securitydescription" 
xmlns="urn: 3gpp: metadata: 2004 : securitydescription" 
xmlns :xs="http: //www. w3 . org/200 l/XMLSchema"> 
<xs : element name="securityDescription"> 

<xs:element name="keyManagement " type=" keyManagementType" minOccurs="0" maxOccurs="l"/> 
<xs : sequence> 

<xs:element name="keyld" type="keyIdType" minOccurs="l" maxOccurs="unbounded"/> 
</xs : sequence> 
<xs : attribute name="conf identialityProtection" 

type="xs : boolean" us e=" optional" 
<xs : attribute name="integrityProtection" 

type="xs : boolean" us e=" optional" 
<xs : attribute name="uiccKeyManagement " 

type="xs :boolean" use="optional" 
</xs : element> 

<xs : complexType name ="keyManagement Type "> 
<xs : sequence> 

<xs:element name="serverURI " type="xs : anyURI " minOccurs=" 1 " maxOccurs="unbounded" /> 
</xs : sequence> 

<xs : attribute name="waitTime" type="xs :unsignedLong" use="optional" default="0"/> 

<xs : attribute name="maxBackOf f " type="xs :unsignedLong" use="optional" default="0"/> 
</xs : complexType> 
<xs : complexType name="keyIdType"> 

<xs : attribute name="identity" type="xs : string" use="required"/> 

<xs ; attribute name="mediaFlow" type="xs : string" use="optional"/> 
</xs : complexType> 
</xs : schema> 

Example of a security description: 

<?xml version=" 1 . " encoding="UTF-8 " ?> 
<securityDescription 

xmlns =" www. example . com/3gppSecurityDescription" 
xmlns : xs="http : //www. w3 . org/200 1/XMLSchema-instance" 
confidentialityProtection="true" 
integrityProtection="true" 
uiccKeyManagement="true"> 
<keyManagement 
waitTime="5" 
maxBackOff="10"> 

<serverURI =http : //register . operator . umts/ /> 
<serverURI ="http:// register2 . operator . umts/ " /> 
< / keyManagement > 

<keyld identity="<someMSKidA>" mediaFlow=224 . 1 . 2 . 3 : 4002 /> 
<keyld identity="<someMSKidB>" mediaFlow=224 . 1 . 2 . 3 : 4004 /> 
</securityDescription> 

5.2.2.4 XML-Schema for MBMS User Service Description 

The root element of the MBMS user service description is the userServiceDescription element. The element is of type 
userServiceDescriptionType. 

Each userServiceDescription_t\&v(\&vA shall have a unique identifier. The unique identifier shall be offered as serviceld 
attribute within the userServiceDescription element and shall be of URN format. 

The userServiceDescription slsvatnl may contain one or more name elements. The intention of a Name element is to 
offer a title of the user service. For each name elements, the language shall be specified according to XML datatypes 
(XML Schema Part 2 [22]). 
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The userServiceDescription element may contain one or more ServiceLanguage elements. Each serviceLanguage 
element represents the available languages of the user services. The language shall be specified according to XML 
datatypes (XML Schema Part 2 [22]). 

Each userServiceDescription element shall contain at least one deliveryMethod element. The deliveryMethod element 
contains the description of one delivery method. The element shall contain one reference to a session description and 
may contain references to one associated delivery procedure and/or one service protection descriptions. The session 
description is further specified in clause 5.2.2.1. 

The deliveryMethod element may contain a reference to an associated delivery procedure description. The description 
and configuration of associated delivery procedures is specified in clause 5.2.2.5. 

The deliveryMethod element may contain a reference to a service protection description. The service protection 
description is specified in clause 5.2.2.3. 

<?xml version="l . 0" encoding="UTF-8"?> 
<xs : schema elementFormDefault="qualif ied" 

targetNamespace="urn: 3gpp: metadata: 2004 : use rservicede script ion" 

xmlns="urn: 3gpp: metadata: 2004 : user servicedescript ion" 

xmlns : xs="http: //www. w3 . org/200 l/XMLSchema"> 

<xs : element name=" userServiceDescription" type="userServiceDescriptionType" /> 

<xs : complexType name="userServiceDescriptionType"> 
<xs : sequence> 

<xs;element name="name" type="nameType" minOccurs="0" 

maxOccurs="unbounded" /> 
<xs:element name="serviceLanguage" type="xs : language" minOccurs="0" 

maxOccurs="unbounded" /> 
<xs; element name="deliveryMethod" type="deliveryiyiethodType" 
maxOccurs="unbounded" /> 
</xs : sequence> 

<xs : attribute name="serviceld" type="xs : anyURI" use="required"/> 
</xs ; complexType> 

<xs : complexType name="deliveryMethodType"> 

<xs : attribute name="associatedProcedureDescriptionURI " 

type="xs : anyURI" use="optional"/> 
<xs : attribute name="protectionDescriptionURI " type="xs : anyURI " 

use="optional"/> 
<xs : attribute name="sessionDescriptionURI" type="xs : anyURI" 
use=" required" /> 
</xs : complexType> 

<xs : complexType name="nameType"> 
<xs : simpleContent> 

<xs : extension base="xs : string "> 

<xs : attribute name="lang" type="xs : language" use="optional"/> 
</xs:extension> 
</xs : simpleContent> 
</xs : complexType> 

</xs : schema> 

5.2.2.5 Example MBMS User Service Description Instances 

The following User Service Description instance is an example of a simple fragment. This fragment includes only the 
mandatory elements. 

<?xml version="l . 0" encoding="UTF-8"?> 
<userServiceDe script ion 

xmlns="www. example . com/ SgppUserServiceDe script ion" 
xmlns : xsi=" http: //www. w3 . org/200 1/XMLSchema-instance " 
user Service I d=" urn: 3gpp: 0010120123hotdog"> 
<deliveryMethod 

sessionDescriptionURI="http : //www. example . com/3gpp/mbms/sessionl . sdp" /> 
</userServiceDescription> 
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The following User Service Description instance is an example of a fuller fragment. 

<?xml version="l . 0" encoding="UTF-8"?> 
<userServiceDe script ion 

xmlns="www. example . com/ 3gppUserServiceDe script ion" 
xmlns : xsi="http: //www. w3 . org/2001 /XMLSchema-instance" 
serviceld="urn: 3gpp: 1234 567 8 90coolcat "> 

<name lang="EN">something in english</name> 
<name lang="DE">something in german</name> 
<name lang="FR">something in f rench</name> 
<name lang="FI">something in f innish</Name> 
<serviceLanguage>EN</serviceLanguage> 
<serviceLanguage>DE</serviceLanguage> 
<deliverYMethod 

sessionDescriptionURI="http : //www. example . com/3gpp/mbms/sessionl . sdp" /> 
<deliveryMethod 

sessionDescriptionURI= http: //www. example ■ com/3gpp/mbms/session2 . sdp 

associatedProcedureDescriptionURI="http: //www. example . com/3gpp/mbms/procedureX.xml"/> 
<deliveryMethod 

sessionDescriptionURI="http : //www. example . com/3gpp/mbms/session3 . sdp" 

associatedProcedureDescriptionURI="http : //www. example . com/3gpp/mbms/procedureY . xml" /> 
<deliveryMethod 

sessionDescriptionURI="http : //www. example . com/3gpp/mbms/session4 . sdp" 
</userServiceDescription> 

5.2.3 User service announcement over a MBMS bearer 

Both the metadata envelope and metadata fragment objects are transported as file objects in the same download session. 

This clause covers both metadata transport and metadata fragmentation aspects of Service Announcement. Service 
Announcement over MBMS bearers is specified. 

To receive a Service Announcement User Service the client shall obtain the session parameters for the related MBMS 
download session transport. This may be using a separate Service Announcement session. 

NOTE: The user service announcements are not protected when sent over MBMS bearer. See 
3GPP TS 33.246 [20] 

5.2.3.1 Supported Metadata Syntaxes 

The MBMS metadata syntax supports the following set of features: 

• Support of carriage of SDP descriptions, and SDP is expected to sufficiently describe at least: MBMS Streaming 
sessions and, MBMS download sessions. 

• Support for multiple metadata syntaxes, such that the delivery and use of more than one metadata syntax is 
possible. 

• Consistency control of metadata versions, between senders and receivers, independent of the transport and bearer 
use for delivery. 

• Metadata fragments are identified, versioned and time-limited (expiry described) in a metadata fragment syntax- 
independent manner (which is a consequence of the previous two features). 

5.2.3.2 Consistency Control and Syntax Independence 

The Metadata Envelope provides information to identify, version and expire metadata fragments. This is specified to be 
independent of metadata fragments syntax and of transport method (thus enabling the use of more than one syntaxes 
and enable delivery over more than a single transport and bearer). 

A metadata envelope may update the time validity of its metadata fragment without changing version if the metadata 
fragment itself has not changed. A newer version (higher version number) of a metadata envelope shall automatically 
expire the earUer version. If the content type (metadata fragment syntax) is recognized and valid, the UE shall use the 
new metadata fragment description. However, if the content type is not recognized or valid, the UE may maintain the 
expired version data until the newer version is correctly received. 
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Service announcement senders shall increment the version by one for each subsequent transported version of a metadata 
fragment. However, a UE shall also accept versions with an increment greater than one (so that they do not fail in the 
case that an intermediate version was not successfully transported). 

5.2.3.3 Metadata Envelope Definition 

The attributes for a metadata envelope and their description is as follows. These attributes shall be supported: 

• metadataURI: A URI providing a unique identifier for the metadata fragment. The metadataURI attribute shall 
be present. 



• 



version: The version number of the associated instance of the metadata fragment. The version number should be 
initialized to one. The version number shall be increased by one whenever the metadata fragment is updated. 
The version attribute shall be present. 

• validFrom: The date and time from which the metadata fragment file is valid. The validFrom attribute may or 
not be present. If not present, the UE should assume the metadata fragment version is valid immediately. 

• validUntil: The date and time when the metadata fragment file expires. The validUntil attribute may or not be 
present. If not present the UE should assume the associated metadata fragment is valid for all time, or until it 
receives a newer metadata envelope for the same metadata fragment describing a validUntil value. 

• contentType: The MIME type of the metadata fragment which shall be used as defined for "Content-Type" in 
RFC 2616 [18]. The contentType attribute shall be present for embedding metadata envelopes. The contentType 
attribute may be present for referencing metadata envelopes. 

The metadata envelope is instantiated using an XML structure. This XML contains a URI referencing the associated 
metadata fragment. The formal schema for the metadata envelope is defined as an XML Schema as follows. 

<?xml version=" 1 . " encocling="UTF-8 " ?> 

<xs ; schema xmlns ; xs="http ; //www. w3 . org/200 1/XMLSchema" 
elementFormDefault=" qualified" 
attributeFormDefault="unqualif ied"> 

<xs:element name="metadataEnvelope" type="metadataEnvelopeType" minOccurs="l" 
maxOccurs="unbounded" /> 
<xs : complexType name="metadataEnvelopeType"> 
<xs : sequence> 

<xs ; element name="metadataFragment " 
type="xs : string" 
minOccurs="0 " 
maxOccurs=" 1 "> 
</xs ; element> 
</xs : sequence> 

<xs : attribute name="metadataURI" 
type="xs : anyURI" 
us e=" required" /> 
<xs : attribute name="version" 

type="xs : positive Integer" 
use=" required" /> 
<xs ; attribute name="validFrom" 

type="xs : dateTime" 
use="optional"/> 
<xs : attribute name =" validUntil" 

type="xs : dateTime" 
use="optional"/> 
<xs : attribute name="contentType" 
type="xs ; string" 
use="optional"/> 
<xs : anyAt tribute processContents="skip" /> 

</xs : element> 
</xs ; schema> 

The element "metadataFragment" shall be encapsulated in the metadata envelope for embedded metadata fragments, 
and shall not be encapsulated where the metadata fragment is not embedded. In the embedded case, 
"metadataFragment" shall contain exactly one embedded metadata fragment as specified by the metadata envelope 
syntax and only one instance of the envelope element shall be used for encapsulating envelopes. 
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An embedded metadata fragment shall be escaped. Generally, an embedded metadata fragment should be escaped by 
placing inside a CDATA section [31]. Everything starting after "<![CDATA[" string and ending at the "]]>" string 
would be ignored by the XML envelope parser (quotes not included). Thus, the embedded parts would appear as 
"<![CDATA[" + metadata_fragment + "]]>". In this case, the complete metadata envelope with embedded metadata 
fragment shall not violate the rules of CDATA section sage [31]. 

In the case of an metadata fragment including the XML for a CDATA section, the embedded metadata fragment may be 
escaped by replacing illegal characters with their ampersand-escaped equivalents [31] (instead of encapsulating the 
whole fragment in a CDATA section). For instance "<" is an illegal character that would be replaced by "<". This 
method is useful to avoid nesting CDATA sections (which is not allowed). 

An metadata fragment which does not adhere to either of these two methods shall not be embedded in a metadata 
envelope, thus it may only be referenced from an referencing metadata envelope. 

5.2.3.4 Delivery of the Metadata Envelope 

An instance of metadata envelope shall be associated with an instance of an metadata fragment by one of two methods: 

• Embedded: The metadata fragment is embedded within the metadata envelope. 

• Referenced: The metadata fragment is referenced from the metadata envelope. 

In the embedded case, the envelope and fragment are, by definition, transported together and in-band of one another. In 
the referenced case, the envelope and fragment shall be transported together in-band of the same transport session. 

MBMS Service Announcement transports shall support delivery of the metadata envelope as a discrete object (XML 
file) for the referenced case. In the referenced case, the MIME type of the metadata fragment should be provided by the 
transport protocol (e.g. as a Content-Type text string). In both cases, the MIME type of the metadata envelope should be 
provided by the transport protocol. 

The Metadata Envelope includes a reference (metadataURI) to the associated metadata fragment using the same URI as 
the fragment file is identified by in the Service Announcement. Thus, Metadata Envelope can be mapped to its 
associated metadata fragment. 

5.2.3.5 Metadata Envelope Transport 

When FLUTE is used as the Service Announcement transport, the metadata envelope object is transported as a file 
object in the same MBMS service announcement download session as its metadata fragment file object (i.e. in-band 
with the metadata fragment session). 

5.2.3.6 Metadata Envelope and Metadata Fragment Association with FLUTE 

The FLUTE service announcement session FDT Instances provide URIs for each transported object. The metadata 
envelope metadataURI field shall use the same URI for the metadata fragment as is used in the FDT Instances for that 
metadata fragment file. Thus, the fragment can be mapped to its associated envelope in-band of a single MBMS 
download session. 

In the referencing case, each metadata envelope and corresponding metadata fragment shall be grouped together by the 
FDT using the grouping mechanism described by clause 7.2.5. This reduces the complexity of requesting both fragment 
and envelope for each pair, thus it is recommended that only the metadata fragment (fileURI) be requested from the 
download client (which will result in both fragment and envelope being received using the grouping mechanism). 

5.2.4 User service announcement using Interactive Announcement 
Function 

NOTE: The User Service Announcement using Interactive Announcement Function was agreed at SA4#34. 
Although text specification is FES. 



£75/ 



3GPP TS 26.346 version 6.0.0 Release 6 



25 



ETSI TS 126 346 V6.0.0 (2005-03) 



5.2.5 Metadata fragment encapsulation to aggregate Service 
Announcement documents 

The present document defines a number of metadata fragments to describe MBMS user services. A metadata fragment 
is a single uniquely identifiable block of metadata. Generally, more than one metadata fragment is necessary to provide 
all necessary parameters to initiate an MBMS User Service. Typically, metadata fragments are provided in separate 
documents. Each metadata fragment is labelled with its MIME type. 

Multipart MIME may be used to encapsulate metadata fragments into an aggregate service announcement document. 
The aggregate document may contain metadata fragments of several MBMS user services. It is recommended, that any 
such aggregate service announcement document contains all the referenced metadata fragments of each MBMS user 
service description it contains (i.e. in the same multipart MIME structure). 

An aggregate service announcement document shall encapsulate metadata fragments according to RFC 2557 [37]. The 
first encapsulated file of an aggregate service announcement document is the root resource. The root resource shall be 
either an MBMS user service description or a metadata envelope (as a referencing index). The service description 
metadata is defined in clause 5.2.2.4. The metadata envelope is defined in clause 5.2.3.3. 

The type field of the multipart/related header shall be set to application/mbms-user-service-description-parameter in 
case the root resource is a user service description instance. The type field of the multipart/related header shall be set to 
application/mbms -envelope in case the root resource is a metadata envelope. 



5.3 



User Service Initiation/Termination 



5.3.1 



Initiation 



MBMS User Service initiation refers to UE mechanisms to set-up the reception of MBMS user service data. During the 
User Service Initiation procedure, a set of MBMS Bearers may be activated. The User Service Initiation procedure takes 
place after the discovery of the MBMS user service. 



MBMSUE 



BM-SC 



2. Security functions 



3. MBMS Activation Request 
1^ ► 



I 



3n. MBMS Activation Request 



Figure 6: Initiation of an MBMS User Service 

1 . The User Service Initiation Procedure is triggered and takes a User Service Description as input that has been 
obtained e.g. by executing the MBMS User Service discovery and announcement functions. 

2. The MBMS UE requests MBMS service keys, if security functions are activated for the MBMS User Service. 
The keys are sent to the UE, after the user is authorized to receive the MBMS service. The request shall be 
authenticated. Details on the security functions are described in 3GPP TS 33.246 [20]. 
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3n. 



The MBMS UE uses the MBMS activation procedure to activate the MBMS Bearer Service. The MBMS 
activation procedure is the MBMS Muhicast Service activation procedure and the MBMS Broadcast activation 
procedure as defined in 3GPP TS 23.246 [4]. In case the MBMS Broadcast Mode is activated, there is no 
activation message sent from the UE to the BM-SC. The activation is locally in the UE. Note that the MBMS 
Bearer Services may already by active and in use by another MBMS User Service. 

In case the MBMS User Service uses several MBMS Bearer Services, the User Service Description contains 
several description items. In that case, the MBMS receiver function repeats the activation procedure for each 
MBMS Bearer Service as described in 2. 



5.3.2 MBMS User Service termination procedure 

MBMS user service termination refers to the UE mechanisms to terminate the reception of MBMS user services. A set 
of MBMS Bearers may be deactivated during this procedure. 



MBMS UE 



1 . Leave 
User Service X 
► 




2. MBMS deactivation Request 



2n. MBMS deactivation Request 



Figure 7: Termination of an IVIBIVIS user service 

1. The User Service termination Procedure is triggered. A reference to the User Service to terminate is provided 
as parameter. 

2. If no other MBMS User Service uses the MBMS Bearer service, the MBMS UE uses the MBMS deactivation 
procedure to deactivate the MBMS Bearer Services. The MBMS deactivation procedure represents the MBMS 
Multicast service deactivation procedure and the MBMS Broadcast deactivation procedure as described in 
3GPP TS 23.246 [4]. In case the MBMS Broadcast Mode is deactivated, there is no message sent to the 
BM-SC. The deactivation is only locally in the UE. 

2n. In case the MBMS User Service uses several Bearer Services, the UE repeats the deactivation procedure for 
each Bearer Service as described in 2. 



5.4 



MBMS Data Transfer Procedure 



MBMS Data Transfer procedure refers to the network (and UE) mechanism to transfer (and receive) data for one 
MBMS User Service on one or several MBMS Bearer Services. 
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NOTE: Security related interactions are not depicted in ttie sequence. 

Figure 8: Procedure of MBMS Data Transfer 

1 . The MBMS Delivery Method for the MBMS User Service is triggered by the MBMS User Service 
Provider. Note, details of the trigger are beyond of the present document. 

2. - 2n. The MBMS Delivery function uses the MBMS Session Start Procedure to the GGSN, possibly through the 

Gmb Proxy function to activate all MBMS Bearer Services, which belong to the MBMS User Service. The 
MBMS Bearer service to be activated is uniquely identified by the TMGI. 

3. - 3n. The data of the MBMS user service are transmitted to all Hstening MBMS UEs. Several MBMS Bearer 

services may be used to transmit the MBMS user service data. MBMS user service data may be integrity 
and/or confidentiality protected. In case MBMS user service data are integrity and/or confidentiality 
protected, MBMS traffic keys are delivered simultaneously on the same or a different MBMS bearer. 

4. - 4n. The MBMS Delivery function uses the MBMS Session Stop procedure to trigger the GGSN, possibly 

through the Gmb Proxy function to release all MBMS Bearer Service for this User Service. A unique 
identifier for the MBMS Bearer service to be deactivated (i.e. the TMGI) is passed on as a parameter. 

5. In case associated delivery procedures are allowed or requested for an MBMS User Service, the MBMS UE 
sends an associated-delivery procedure request to the associated -delivery function. The BM-SC may 
authenticate the user. See 3GPP TS 33.246 [20]. The MBMS UE may need to wait a random time before it 
starts the associated delivery procedure according to clause 9. 



5.5 



MBMS Protocols 



Figure 9 illustrates the protocol stack used by MBMS User services. The grey-shaded protocols and functions are 
outside of the scope of the present document. MBMS security functions and the usage of HTTP-digest and SRTP are 
defined in 3GPP TS 33.246 [20]. 
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Figure 9: Protocol stack view of the MBMS User Services 



Introduction on Delivery IVIethods 



Two delivery methods are defined in the present document - the download delivery method and the streaming delivery 
method. MBMS delivery methods make use of MBMS bearers for content delivery but may also use the associated 
procedures defined in clause 9. 

Use of MBMS bearers by the download delivery method is described in clause 7. The File Repair Procedure and the 
Reception Reporting Procedure (described in clause 9) may be used by the download delivery method. 

Use of MBMS bearers by the streaming delivery method is described in clause 8. 



Download Delivery Method 



7.1 



Introduction 



MBMS download delivery method uses the FLUTE protocol (RFC 3926 [9]) when delivering content over MBMS 
bearers. Usage of FLUTE protocol is described in this clause. 

FLUTE is built on top of the Asynchronous Layered Coding (ALC) protocol instantiation (RFC 3450 [10]). ALC 
combines the Layered Coding Transport (LCT) building block [11], a congestion control building block and the 
Forward Error Correction (FEC) building block (RFC 3452 [12]) to provide congestion controlled reliable 
asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. As mentioned in 
(RFC 3450 [10]), congestion control is not appropriate in the type of environment that MBMS download delivery is 
provided, and thus congestion control is not used for MBMS download delivery. See figure 10 for an illustration of 
FLUTE building block structure. FLUTE is carried over UDP/IP, and is independent of the IP version and the 
underlying link layers used. 
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Figure 10: Building block structure of FLUTE 
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ALC uses the LCT building block to provide in-band session management functionality. The LCT building block has 
several specified and under-specified fields that are inherited and further specified by ALC. ALC uses the FEC building 
block to provide reliability. The FEC building block allows the choice of an appropriate FEC code to be used within 
ALC, including using the no-code FEC code that simply sends the original data using no FEC coding. ALC is under- 
specified and generally transports binary objects of finite or indeterminate length. FLUTE is a fully-specified protocol 
to transport files (any kind of discrete binary object), and uses special purpose objects - the File Description Table 
(FDT) Instances - to provide a running index of files and their essential reception parameters in-band of a FLUTE 



7.2 FLUTE usage for MBMS download 

The purpose of download is to deliver content in files. In the context of MBMS download, a file contains any type of 
MBMS data (e.g. 3GPP file (AudioA^ideo), Binary data. Still images. Text, Service Announcement metadata). 

In the present document the term "file" is used for all objects carried by FLUTE (with the exception of the FDT 
Instances). 

UE applications for MBMS user services built upon the download delivery method have three general approaches to 
getting files from the FLUTE receiver for a joined session: 

• Promiscuous: Instruct FLUTE to promiscuously receive all files available. Promiscuous reception can be 
suitable for single purpose sessions (generally with limited number and/or size of files) although uncertainty over 
the quality and content of files makes this approach generally undesirable. 

• One-copy: Instruct FLUTE to receive a copy of one or more specific files (identified by the fileURI) - and 
potentially leaving the session following reception of one copy of all the specified files. Specifying the download 
file ensures that the UE has an upper bound to the quantity of files downloaded. One-copy reception requires 
prior knowledge of the file identifiers (fileURIs). 

• Keep-updated: Instruct FLUTE to receive one or more specific files and continue to receive any updates to 
those files. As with one-copy, the keep-updated approach bounds the quantity of files downloaded and requires 
prior knowledge of the file identifiers. 

NOTE: The present document does not prevent or endorse changing download reception approach, and any 

related file list, during the life of the download session. Discovery of session content lists (including file 
lists) out-of-band of the delivery method sessions is beyond the scope of the present document. 

MBMS clients and servers supporting MBMS download shall implement the FLUTE specification (RFC 3926 [9]), as 
well as ALC (RFC 3450 [10]) and LCT (RFC 3451 [11]) features that FLUTE inherits. In addition, several optional and 
extended aspects of FLUTE ,as described in the following clauses, shall be supported. 

7.2.1 Fragmentation of Files 

Fragmentation of files shall be provided by a blocking algorithm (which calculates source blocks from source files) and 
a symbol encoding algorithm (which calculates encoding symbols from source blocks). 

Exactly one encoding symbol shall be carried in the payload of one FLUTE packet. 

7.2.2 Symbol Encoding Algorithm 

The "Compact No-Code FEC scheme" - RFC 3452 [12] (FEC Encoding ID 0, also known as "NuU-FEC") shall be 
supported. 

NOTE: The support of any other symbol encoding scheme is still under discussion. 



7.2.3 Blocking Algorithm 



The "Algorithm for Computing Source Block Structure" described within the FLUTE specification (RFC 3926 [9]) 
shall be used. 
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7.2.4 Congestion Control 

For simplicity of congestion control, FLUTE channelization shall be provided by a single FLUTE channel with single 
rate transport. 

7.2.5 Content Encoding of Files for Transport 

Files may be content encoded for transport, as described in [9], in the Download delivery method using the generic 
GZip algorithm RFC 1952 [42]. UEs shall support GZip content decoding of FLUTE files (GZIP RFC 1952 [42], 
clause 9). 



7.2.6 Transport File Grouping 



Files downloaded as part of a multiple-file delivery are generally related to one another. Examples includes web pages, 
software packages, and the referencing metadata envelopes and their metadata fragments. FLUTE clients analyse the 
XML-encoded FDT Instances as they are received, identify each requested file, associate it with FLUTE packets (using 
the TOI) and discover the relevant in-band download configuration parameters of each file. 

An additional "group" field in the FLUTE FDT instance and file elements enables logical grouping of related files. A 
FLUTE receiver should download all the files belonging to all groups where one or more of the files of those groups 
have been requested. However, a UE may instruct its FLUTE receiver to ignore grouping to deal with special 
circumstances, such as low storage availability. 

The group names are allocated by the FLUTE sender and each specific group name shall group the corresponding files 
together as one group, including files describes in the same and other FDT Instances, for a session. 

Group field usage in FDT Instances is shown in the FDT XML schema (clause 7.2.9). Each file element of an FDT 
Instance may be labelled with zero, one or more group names. Each FDT Instance element may be labelled with zero, 
one or more group names which are inherited by all files described in that FDT Instance. 

7.2.7 Signalling of Parameters with Basic ALC/FLUTE Headers 

FLUTE and ALC mandatory header fields shall be as specified in [9, 10] with the following additional specializations: 

• The length of the CCI (Congestion Control Identifier) field shall be 32 bits and it is assigned a value of zero 
(C=0). 

• The Transmission Session Identifier (TSI) field shall be of length 16 bits (S=0, H=l, 16 bits). 

• The Transport Object Identifier (TOI) field should be of length 16 bits (0=0, H=l). 

• Only Transport Object Identifier (TOI) (zero) shall be used for FDT Instances. 

• The following features may be used for signalling the end of session and end of object transmission to the 
receiver: 

The Close Session flag (A) for indicating the end of a session. 

The Close Object flag (B) for indicating the end of an object. 

In FLUTE the following applies: 

• The T flag shall indicate the use of the optional "Sender Current Time (SCT)" field (when T=l). 

• The R flag shall indicate the use of the optional "Expected Residual Time (ERT)" field (when R=l). 

• The LCT header length (HDR_LEN) shall be set to the total length of the LCT header in units of 32-bit words. 

• For "Compact No-Code EEC scheme" [12], the payload ID shall be set according to RFC 3695 [13] such that a 
16 bit SBN (Source Block Number) and then the 16 bit ESI (Encoding Symbol ID) are given. 
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7.2.8 Signalling of Parameters with FLUTE Extension Headers 

FLUTE extension header fields EXT_FDT, EXT_FTI , EXT_CENC [9] shall be used as follows: 

• EXT_FTI shall be included in every FLUTE packet carrying symbols belonging to any FDT Instance. 

• FLUTE packets carrying symbols of files (not FDT Instances) shall not include an EXT_FTI. 

• FDT Instances shall not be content encoded and therefore EXT_CENC shall not be used. 
In FLUTE the following applies: 

• EXT_FDT is in every FLUTE packet carrying symbols belonging to any FDT Instance. 

• FLUTE packets carrying symbols of files (not FDT instances) do not include the EXT_FDT. 

7.2.9 Signalling of Parameters with FDT Instances 

The FLUTE FDT Instance schema (RFC 3926 [9]) shall be used. In addition, the following applies to both the session 
level information and all files of a FLUTE session. 

The inclusion of these FDT Instance data elements is mandatory according to the FLUTE specification: 

• Content-Location (URI of a file). 

• TOI (Transport Object Identifier of a file instance). 

• Expires (expiry data for the FDT Instance). 

Additionally, the inclusion of these FDT Instance data elements is mandatory: 

• Content-Length (source file length in bytes). 

• Content-Type (content MIME type). 

• FEC-OTI-Maximum-Source-Block-Length. 

• FEC-OTI-Encoding-Symbol-Length. 

• FEC-OTI-Max-Number-of-Encoding-Symbols. 

NOTE 1 : RFC 3926 [9] describes which part or parts of an FDT Instance may be used to provide these data 
elements. 

These optional FDT Instance data elements may or may not be included for FLUTE in MBMS: 

• Complete (the signalling that an FDT Instance provides a complete, and subsequently unmodifiable, set of file 
parameters for a FLUTE session may or may not be performed according to this method). 

• FEC-OTI-FEC-Instance-ID. 

• Content-Encoding. 

NOTE 2: The values for each of the above data elements are calculated or discovered by the FLUTE sender. 
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7.2.10 FDT Schema 

The following XML Schema shall be use for the FDT Instance: 

<?xml version=" 1.0" encoding="UTF-8 " ?> 

<xs : schema xmlns : xs="http : //www. w3 . org/200 1/XMLSchema" 
xmlns : f l="http : //www. example . com/ flute" 
elementFormDef ault : xs="qualif led" 

tar get Name space : xs="http : //www. example . com/f lute"> 
<xs : element name= "FDT- Instance "> 
<xs : complexType> 
<xs : sequence> 

<xs : element name="File" maxOccurs= "unbounded" > 
<xs : complexType> 

<xs : sequence> 

<xs : element name=" Group" type="xs : string" minOccurs="0 " maxOccurs= "unbounded" /> 
</xs : sequence> 
<xs : any processContents="skip" minOccurs="0 " maxOccurs= "unbounded" /> 

<xs : attribute name=" Content -Location" type="xs : anyURI " us e=" required" /> 

<xs : attribute name="TOI " type="xs : positive Integer" us e=" required" /> 

<xs : attribute name =" Content -Length" type="xs : unsignedLong" us e=" optional" /> 

<xs : attribute name=" Transfer-Length" type="xs : unsignedLong" us e=" optional" /> 

<xs : attribute name=" Content -Type" type="xs : string" use="optional" /> 

<xs : attribute name=" Content -Encoding" type="xs : string" us e=" optional" /> 

<xs : attribute name="Content-MD5" type="xs : base64Binary " us e=" optional" /> 

<xs : attribute name="FEC-OTI-FEC-Encoding-ID" type="xs : unsignedLong" use="optional"/> 

<xs : attribute name= "FEC-OT I -FEC- Instance- ID" type="xs : unsignedLong" use="optional"/> 

<xs : attribute name="FEC-OTI-Maximum-Source-Block-Length" 

type="xs : unsignedLong" use="optional"/> 
<xs : attribute name="FEC-OTI-Encoding-Symbol-Length" 

type="xs : unsignedLong" use="optional"/> 
<xs : attribute name=" FEC-OT I -Max-Number-of-Encoding- Symbols " 

type="xs : unsignedLong" use="optional" /> 
<xs : anyAt tribute processContents="skip"/> 
</xs : complexType> 
</xs : element> 
</xs : sequence> 

<xs : sequence> 

<xs : element name=" Group" type="xs : string" minOccurs=" " maxOccurs= "unbounded" /> 
</xs : sequence> 

<xs : any processContents="skip" minOccurs="0 " maxOccurs= "unbounded" /> 

<xs : attribute name= "Expires " type="xs : string" use=" required" /> 

<xs : attribute name=" Complete" type="xs : boolean" us e=" optional" /> 

<xs : attribute name=" Content -Type" type="xs : string" use="optional" /> 

<xs : attribute name=" Content -Encoding" type="xs : string" us e=" optional" /> 

<xs : attribute name= "FEC-OT I -EEC-Encoding- ID" type="xs : unsignedLong" use="optional"/> 

<xs : attribute name= "FEC-OT I-FEC- Instance- ID" type="xs : unsignedLong" use="optional"/> 

<xs : attribute name="FEC-OTI-Maximum-Source-Block-Length" 

type="xs : unsignedLong" use="optional"/> 
<xs : attribute name="FEC-OTI-Encoding-Symbol-Length" 

type="xs : unsignedLong" us e=" optional" /> 
<xs : attribute name=" FEC-OT I -Max-Number-of-Encoding- Symbols " 

type="xs : unsignedLong" us e=" optional" /> 
<xs : anyAt tribute processContents="skip" /> 
</xs : complexType> 
</xs : element> 
</xs : schema> 

7.3 SDP for Download Delivery Method 
7.3.1 Introduction 

RFC 3926 [9] describes required and optional parameters for FLUTE session and media descriptors. This clause 
specifies SDP for FLUTE session that is used for the MBMS download and service announcement sessions. The formal 
specification of the parameters is given in ABNF (RFC 2234 [23]). 
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7.3.2 SDP Parameters for MBMS download session 

The semantics of a Session Description of an MBMS download session includes the following parameters: 

• The sender IP address. 

• The number of channels in the session. 

• The destination IP address and port number for each channel in the session per media. 

• The Transport Session Identifier (TSI) of the session. 

• The start time and end time of the session. 

• The protocol ID (i.e. FLUTE/UDP). 

• Media type(s) and fmt-list. 

• Data rate using existing SDP bandwidth modifiers. 

• Mode of MBMS bearer per media. 

• FEC capabilities and related parameters. 

• Service-language(s) per media. 

This list includes the parameters required by FLUTE - RFC 3926 [9] 

These shall be expressed in SDP (RFC 2327 [14], draft-ietf-mmusic-sdp-srcfilter [15], RFC 3266 [16]) syntax 
according to the following clauses. 

7.3.2.1 Sender IP address 

There shall be exactly one IP sender address per MBMS download session, and thus there shall be exactly one IP source 
address per complete MBMS download session SDP description. The IP source address shall be defined according to 
the source-filter attribute ("a=source-filter:") (RFC 2327 [14] and draft-ietf-mmusic-sdp-srcfilter [15]) for both IPv4 and 
IPv6 sources, with the following exceptions: 

1 . Exactly one source address may be specified by this attribute such that exclusive-mode shall not be used and 
inclusive-mode shall use exactly one source address in the <src-list>. 

2. There shall be exactly one source-filter attribute per complete MBMS download session SDP description, and 
this shall be in the session part of the session description (i.e. not per media). 

3. The * value shall be used for the <dest-address> subfield, even when the MBMS download session employs only 
a single LCT (multicast) channel. 

7.3.2.2 Number of channels 

Only one FLUTE channel is allowed per FLUTE session in the present document and thus there is no further need for a 
descriptor of the number of channels. 

7.3.2.3 Destination IP address and port number for channels 

The FLUTE channel shall be described by the media-level channel descriptor. These channel parameters shall be per 
channel: 

• IP destination address. 

• Destination port number. 
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The IP destination address shall be defined according to the "connection data" field ("c=") of SDP (RFC 2327 [14] and 
draft-ietf-mmusic-sdp-srcfilter [15]). The destination port number shall be defined according to the <port> sub-field of 
the media announcement field ("m=") of SDP (RFC 2327 [14] and draft-ietf-mmusic-sdp-srcfilter [15]). 

The presence of a FLUTE session on a certain channel shall be indicated by using the "m-line" in the SDP description 
as shown in the following example: 

m=application 12345 FLUTE/UDP 

c=IN IP6 FF1E:03AD::7F2E:172A:1E24/1 

In the above SDP attributes, the m-line indicates the media used and the c-line indicates the corresponding channel. 
Thus, in the above example, the m-line indicates that the media is transported on a channel that uses FLUTE over UDP. 
Further, the c-line indicates the channel address, which, in this case, is an IPv6 address. 

7.3.2.4 Transport Session Identifier (TS!) of the session 

The combination of the TSI and the IP source address identifies the FLUTE session. Each TSI shall uniquely identify a 
FLUTE session for a given IP source address during the time that the session is active, and also for a large time before 
and after the active session time (this is also an LCT requirement - RFC 3451 [11]). 

The TSI shall be defined according the SDP descriptor given below. There shall be exactly one occurrence of this 
descriptor in a complete FLUTE SDP session description and it shall appear at session level. 

The syntax in ABNF is given below: 

• sdp-flute-tsi-Une = "a" "=" "flute-tsi" ":" integer CRLF. 

• integer = as defined in RFC 2327 [14]. 

7.3.2.5 Multiple objects transport indication 

RFC 3626 [9] requires the use of the Transport Object Indentifier (TOI) header field (with one exception for packets 
with no payload when the A flag is used). The transport of a single FLUTE file requires that multiple TOIs are used 
(TOI for FDT Instances). Thus, there is no further need to indicate to receivers that the session carries packets for 
more than one object and no SDP attribute (or other FLUTE out of band information) is needed for this. 

7.3.2.6 Session Timing Parameters 

A MBMS download session start and end times shall be defined according to the SDP timing field ("t=") 
(RFC 2327 [14] and draft-ietf-mmusic-sdp-srcfilter [15]). 

7.3.2.7 Mode of MBMS bearer per media 

A new MBMS bearer mode declaration attribute is defined which results in, e.g.: 

• a=mbms-mode:broadcast 1234 

Where any media for the MBMS multicast mode are described, the MBMS bearer mode declaration attribute shall not 
be used at session level. The MBMS bearer mode declaration attribute shall not be used at media level for media flows 
on the MBMS multicast mode. The MBMS bearer mode declaration attribute shall be used to described MBMS 
broadcast mode media. 

The MBMS bearer mode declaration attribute may be session-level (where all media are broadcast (and so becomes the 
default for all media); and media-level to specify differences between media. 

• mbms-bearer-mode-declaration-line = "a=mbms-mode:" "broadcast" SP tmgi CRLF: 

- tmgi=l*DIGIT 

The Temporary Mobile Group Identity (tmgi) information element is defined in RFC 3267 [33]. Only octets 3 to 5 or 
octets 3 to 8 are encoded in tmgi attribute as a decimal number. Octet 3 is the most significant octet. 
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7.3.2.8 FEC capabilities and related parameters 

A new FEC-declaration attribute is defined which resuhs in, e.g.: 

• a=FEC-declaration:0 encoding-id=128; instance-id=0 

This can be session-level (and so the first instance (fec-ref=0) becomes the default for all media) and media-level to 
specify differences between media. This is optional as the information will be available elsewhere (e.g. FLUTE FDT 
Instances). If this attribute is not used, and no other FEC-OTI information is signaled to the UE by other means, the UE 
may assume that support for FEC id is sufficient capability to enter the session. 

A new FEC-declaration attribute shall be defined which results in, e.g.: 

• a=FEC:0 

This is only a media-level attribute, used as a short hand to inherit one of one or more session-level FEC -declarations to 
a specific media. 

The syntax for the attributes in ABNF - RFC 2234 [23] is: 

• sdp-fec-declaration-line = "a=FEC -declaration:" fec-ref SP fec-enc-id ";" [SP fec-inst-id] CRLF 

• fec-ref = 1*DIGIT (value is the SDP-internal identifier for FEC-declaration). 

• fec-enc-id = "encoding-id=" enc-id 

• end-id = 1 *DIGIT (value is the FEC Encoding ID used). 

• fec-inst-id = "instance-id=" inst-id 

• inst-id = 1 *DIGIT (value is the FEC Instance ID used). 

• sdp-fec-Hne = "a=FEC: " fec-ref CRLF 

• fec-ref = 1*DIGIT (value is the FEC-declaration identifier). 

7.3.2.9 Service-language(s) per media 

The existing SDP attribute "a=lang" is used to label the language of any language-specific media. The values are taken 
from RFC 3066 [73] which in turn takes language and (optionally) country tags from ISO 639 [74] and ISO 3661 [75] 
(e.g. "a=lang:EN-US"). These are the same tags used in the User Service Description XML. 

7.3.2.10 Bandwidth Specification 

The maximum bit-rate required by this FLUTE session shall be specified using the "AS" bandwidth modifier 
RFC 2327 [14] on media level. The Application Specific (AS) bandwidth for a FLUTE session shall be the largest sum 
of the sizes of all packets transmitted during any one second long period of the session, expressed as kilobits. The size 
of the packet shall be the complete packet, i.e. IP, UDP and FLUTE headers, and the data payload. 
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7.3.3 SDP Examples for FLUTE Session 

Here is a full example of SDP description describing a FLUTE session: 

v=0 

o=userl23 2890844526 2890842807 IN IP6 2201 : 056D : : 112E : 144A: 1E24 

s=File delivery session example 

i=More information 

t=2873397496 2873404696 

a=mbms-mode : broadcast 1234 

a=FEC-declaratlon: encodlng-ld=128 ; lnstance-ld=0 

a=source- filter : Incl IN IP6 * 2001 : 210 : 1 : 2 : 240 : 96FF :FE25 : 8EC9 

a=flute-tsl : 3 

m=appllcatlon 12345 FLUTE /UDP 

C=IN IP 6 FF1E:03AD: :7F2E:172A:1E24/1 

b=64 

a=lang:EN 

a=FEC:0 



8 Streaming delivery method 

8.1 Introduction 



The purpose of the MBMS streaming delivery method is to deliver continuous multimedia data (i.e. speech, audio and 
video) over an MBMS bearer. This delivery method complements the download delivery method which consists of the 
delivery of files. The streaming delivery method is particularly useful for multicast and broadcast of scheduled 
streaming content. 



8.2 Transport protocol 



RTP is the transport protocol for MBMS streaming delivery. RTF provides means for sending real-time or streaming 
data over UDP and is already used for the transport of PSS in 3GPP. RTP provides RTCP for feedback about the 
transmission quality. The transmission of RTCP packets in the downlink (sender reports) is allowed. In this version of 
the specification, RTCP RR shall be turned off by SDP RR bandwidth modifiers. Note that in the context of MBMS 
detection of link aliveness is not necessary. 



8.2.1 RTP pay load formats for media 



The RTP payload formats and corresponding MIME types are aligned with those defined in PSS Rel-6 3GPP TS 26.234 
[47] as much as possible. For RTP/UDP/IP transport of continuous media the following RTP payload formats shall be 
used: 

• AMR narrow-band speech codec (see clause 10.2) RTP payload format according to RFC 3267 [33]. A MBMS 
client is not required to support multi-channel sessions. 

• AMR wideband speech codec (see clause 10.2) RTP payload format according to RFC 3267 [33]. A MBMS 
client is not required to support multi-channel sessions. 

• Extended AMR-WB codec (see clause 10.3) RTP payload format according to [34]. 

• Enhanced aacPlus codec (see clause 10.3): RTP payload format and MIME types according to RFC 3640 [41], 
namely the Low Bit-Rate AAC or the High Bit-Rate AAC modes. 

NOTE: RFC3640 [41] was agreed at SA4#34 pending evidence of the benefits are shown at SA4#35. 
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• H.264 (AVC) video codec (see clause 10.4) RTP payload format according to RFC 3987 [35]. An MBMS client 
supporting H.264 (AVC) is required to support all three packetization modes: single NAL unit mode, non- 
interleaved mode and interleaved mode. For the interleaved packetization mode, an MBMS client shall support 
streams for which the value of the "sprop-deint-buf-req" MIME parameter is less than or equal to MaxCPB * 
1000 / 8, inclusive, in which "MaxCPB" is the value for VCL parameters of the H.264 (AVC) profile and level 
in use, as specified in [TBD]. 

8.2.2 FEC mechanism for RTP 

NOTEl: This scheme is intended to be generic. If the selected FEC scheme(s) does not fit, it can be modified. 

NOTE2: The specification text is FFS. 

The generic mechanism for systematic FEC of RTP streams consists of two RTP payload formats, one for FEC source 
packets, one for FEC repair packets, and their related signaling. In addition, the construction of a FEC source block is 
specified. A receiver supporting the streaming delivery method shall support the payload format for FEC source 
packets and shall support the payload format for FEC repair packets. 

At the sender, the mechanism begins by processing original RTP packets to create: 

(i) a stored copy of the original packets in the form of a source block; and 

(ii) FEC source packets for transmission to the receiver. 

After constructing the source block from the original RTP packets to be protected, the FEC encoder generates the 
desired amount of FEC protection data, i.e. encoding symbols. These encoding symbols are then sent using the FEC 
repair packet payload format to the receiver. The FEC repair packets use an SSRC different from the original RTP 
packets' SSRC, but are sent within the same RTP session. Doing so avoids non-continuous sequence numbering spaces 
for both the FEC repair packets and the original RTP packets. 

The receiver recovers the original RTP packets directly from the FEC source packets and buffers it at least the min- 
buffer-time to allow time for the FEC repair. The receiver uses the FEC source packets to construct a (potentially 
incomplete) copy of the source block, using the Source FEC Payload ID in each packet to determine where in the source 
block the packet should be placed. 

If any FEC source packets have been lost, but sufficient FEC source and FEC repair packets have been received, FEC 
decoding can be performed to recover the FEC source blockThe original RTP packets can then be extracted from the 
source block and buffered as normal. If not enough FEC source and repair packets were received, only the original 
packets that were received as FEC source packets will be available. The rest of the original packets are lost. 

Note that the receiver must be able to buffer all the original packets and allow time for the FEC repair packets to arrive 
and FEC decoding to be performed before media playout begins. The min-buffer-time MIME parameter specified in 
clause 8.2.1.12 helps the receiver to determine a sufficient duration for initial start-up delay. 

The Source and Repair FEC payload IDs are used to associate the FEC source packets and FEC repair packets, 
respectively, to a source block. The Source and Repair FEC payload ID formats are part of the definition of the FEC 
scheme. Each FEC scheme is identified by an FEC encoding ID and FEC instance ID value for underspecified FEC 
encoding IDs. One FEC scheme for the streaming delivery method is specified in clause 8.2.1.6. Any FEC schemes 
using the RTP payload formats defined in the present document shall be systematic FEC codes and may use different 
FEC payload ID formats for FEC source packets and FEC repair packets. 

The protocol architecture is illustrated in figure 1 1 . 
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Figure 1 1 : FEC mechanism for RTP interaction diagram 



Sending Terminal Operation (Informative) 



It is assumed that the sender has constructed original RTP packets comprising RTP header, profile specific extensions, 
variable sized fields such as CSRC list and extension headers, the payload headers and the payload. 

In order to FEC protect a sequence of such packets, the sender constructs a source block as specified in clause 8.2.1.6 to 
which the FEC algorithm is to be applied, and encapsulates the original RTP source packet data within FEC source 
packets. The following operations describe a possible way to generate compliant FEC source packet and FEC repair 
packet streams: 

1 . Each original RTP packet is placed in the source block. In doing so, the Source FEC Payload ID information to 
be included in the FEC payload ID of the FEC source packet can be determined. See clause 8.2.1.4 for details. 

2. The FEC source packet is constructed according to clause 8.2.1.4. It is identified by the use of an RTP Payload 
Type that indicates the use of the FEC source packet payload format encapsulating an RTP packet of the original 
Payload Type. 

3. The FEC source packet generated is sent according to RTP procedures defined in RFC 3267 [33]. 

When a source block is complete, the FEC encoder generates encoding symbols and places these symbols into FEC 
repair packets, to be conveyed in the same RTP session as the FEC source packets, but using a different SSRC. These 
repair packets are sent using normal RTP procedures. 
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8.2.2.2 



Receiving Terminal Operation (Informative) 



The following describes a possible receiver algorithm, when receiving an FEC source or repair packet in a given RTP 
session: 

1 . If a FEC source packet (with a Payload Type that indicates the FEC source packet payload format) is received: 

a. The original FEC packet is reconstructed by removing the Payload ID and changing the Payload type back to 
the original Payload Type (which can be derived from the received Payload Type). The resulting packet is 
buffered to allow time for the FEC repair. 

b. The resulting packet is placed into the source block according to the information in the Source FEC Payload 
ID and the source block format described in clause 8.2.1.3. 

2. If an FEC repair packet is received (as indicated by the Payload Type), the contained encoding symbols are 
placed into the FEC source block according to the Repair FEC Payload ID. 

3. If at least one source packet is missing (as detected by the gaps in the sequence number space), then FEC 
decoding may be desirable. The FEC decoder determines if the source block constructed in steps 1 and 2 
contains enough symbols from the source and repair packets for decoding and, if so, performs the decoding 
operation. 

4. Any missing source packets that were reconstructed during the decoding operation are then buffered as normal 
received RTP packets (see step la above). 

Note that the above procedure may result in that not all original RTP packets are recovered, and they must simply be 
marked as being lost. 

Obviously, buffering and packet re-ordering arerequired to insert any reconstructed packets in the appropriate place in 
the packet sequence. To allow receivers to determine the minimal start-up buffering requirement for FEC decoding, the 
min-buffer-time MIME parameter indicates a minimum initial buffering time that is sufficient regardless of the position 
of the stream in which the reception starts. 



8.2.2.3 



RTCP Statistics 



RTCP Statistics, if required, shall be based on the FEC source packets and FEC repair packets and not on the original 
source RTP packets. The synchronization information (RTP and NTP Timestamp fields) for the source packet stream 
shall be identical to the original packet streams as the RTP timestamp values for the source is not modified between 
source and original packets. 

In the context of MBMS 3GPP Rel-6, RTCP RR shall be turned off by SDP RR bandwidth modifiers. 



8.2.2.4 



RTP Payload format for source RTP packets 



The RTP payload format for FEC source packets shall be used to encapsulate an original RTP packet. This payload 
format is identified by the media type defined in clause 8.2.1.14. As depicted in figure 12, it consists of the RTP 
header, the RTP payload header in the form of the Source FEC payload ID, and the Payload. 
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Figure 12: Structure of the FEC payload format for source RTP packets 
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The Payload Type field in the RTP header shall be a value indicating the FEC source packet payload format carrying 
payload of the original Payload Type. The remaining fields in the RTP header shall be set to the same values as those of 
the original source RTP packet. 

The RTP payload shall consist of the Source FEC Payload ID followed by the original RTP packet's payload. 

The Source FEC Payload ID consists of information required for the operation of the FEC algorithm. Its construction is 
specified in clause 8.2.1.8. 

8.2.2.5 RTP Payload Format for Repair packets 

The RTP payload format for FEC repair packets carries, as its payload, encoding symbols generated by the FEC 
encoding process. The format of a FEC repair packet is depicted in figure 13. The RTP payload consists of the Repair 
FEC Payload ID, and one or more encoding symbols. The RTP payload format is identified by the media type defined 
in clause 8.1.2.13. 



RTP Header 



Repair FEC Payload ID 



FEC encoding symbols 



Content and Size 
of FEC payload 
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on FEC encoding 
and instance ID. 



> RTP Payload 



Figure 13: RTP payload structure for repair RTP packets 

The RTP header information for the FEC repair packet is set as follows: 

Marker bit: The marker bit shall be set 1 for the last FEC repair packet sent for each source block, and otherwise 
set to 0. 

Timestamp: The timestamp rate shall be 10 kHz and shall be set to a time corresponding to the packet's transmission 
time. The timestamp value has no use in the actual FEC protection process and is only set to a value to produce 
reasonable resolution for buffer handling, arrival measuring and jitter calculation. 

Sequence number: Is set in accordance with RFC 3550 [6]. The sequence number is primarily used to detect losses of 
the FEC repair packets. All FEC repair packets for a source block shall be sent in consecutive order, and be complete 
before starting the transmission of the next source block. 

Payload type (PT): Identifies the payload format for FEC repair packets and the FEC parameters for the payload. The 
FEC encoding ID, FEC instance ID, and any additional FEC object transmission information is all determined through 
the Payload Type. 

SSRC: One SSRC is used per source SSRC. The SSRC used by the FEC repair packet payload format shall be different 
the one used by the FEC source packets. The binding of the source SSRC to the repair SSRC shall be performed using 
the RTCP SDES CNAME, which shall be identical for the two SSRCs. 

The Repair FEC Payload ID is of a fixed in size for a given Payload Type, as the Payload Type identifies the FEC 
scheme employed and its parameters (if any). A FEC scheme and its Source and Repair FEC payload ID formats are 
defined in clause 8.2.1.6. 

8.2.2.6 Structure of the FEC source block 

This clause defines the layout of the FEC source block. 

The FEC source block shall contain at least one complete RTP packet (excluding the IP and UDP headers), and two 
octets indicating the length of the RTP packet. Note: this implies that no RTP packet be larger than the length of the 
FEC source block minus 2. 



£75/ 



3GPP TS 26.346 version 6.0.0 Release 6 



41 



ETSI TS 126 346 V6.0.0 (2005-03) 



Let 

n be the number of RTP packets in the source block, n is determined dynamically during the source block 
construction process. 

Ri denote the octets of the RTP header, payload header(s), and RTP payload of the /th RTP packet to be added to 
the source block. 

Z, be the length of /?, in octets. 

L, denote two octets representing the value of Z, in network byte order (high order octet first). 

Si be the smallest integer such that s,T >= (li+2). 

Pi denote i,T-( l„+2) zero octetsNote: P, are padding octets to align the start of each RTP packet with the start of a 
symbol. 

T be the source symbol size in bytes. 

Then, the source block is constructed by concatenating L„ /?,, P, for / = 1, 2, ... n. and the source block size, S = sum 
{siT, /=!, ..., n}. 



8.2.2.7 



FEC block Construction algorithm and example (informative) 



When the original RTP packet is placed into the source block, the value of L is first written as a two-byte value in 
network byte order (i.e. with high order byte first) into the first available bytes in the source block, followed by the RTP 
packet itself (including the RTP header, but not the IP/UDP headers). Following this, if the next available byte is not the 
first byte of a new symbol, then padding bytes up to the next symbol boundary shall be included using the value in 
each byte. As long as any source RTP packets remain to be placed, the procedure is repeated starting each RTP packet 
length indicator at the start of the next encoding symbol. 

An example of forming a source block is given in figure 14 below. In this example, three RTP packets of lengths 26, 52 
and 103 have been placed into a source block with symbol size T = 16 bytes. Each entry in Figure 14 is a byte and the 
rows correspond to the source symbols and are numbered from to 12. Bij denotes the (j+l)th byte of the (i+l)th RTP 
packet. 



26 


^0,0 


60,1 


^0,2 


^0,3 


60,4 


Bo.5 


60,6 


60,7 


60,8 


60,9 


60,10 


60,11 


60,12 


60,13 


^0,14 


^0,15 


^0,16 


^0,17 


^0,1 8 


^0,19 


^0,20 


^0,21 


6o,22 


60,23 


60,24 


60,25 














52 


ei,o 


61,1 


61,2 


61,3 


61,4 


61,5 


61,6 


61,7 


61,8 


61,9 


61,10 


61,11 


61,12 


61,13 


^1,14 


^1,15 


^1,16 


^1,17 


^1,18 


^1,19 


^1,20 


^1,21 


6l,22 


61,23 


61,24 


61,25 


61 ,26 


61,27 


61 ,28 


61,29 


^1,30 


^1,31 


^1,32 


^1,33 


^1,34 


^1,35 


^1,36 


^1,37 


6l,38 


61,39 


61,40 


61,41 


61,42 


61,43 


61,44 


61,45 


^1,46 


^1,47 


^1,48 


^1,49 


^1,50 


^1,51 
































103 


62,0 


62,1 


62,2 


62,3 


62,4 


62,5 


62,6 


62,7 


62,8 


62,9 


62,10 


62,11 


62,12 


62,13 


^2,14 


^2,15 


^2,16 


^2,17 


^2,1 8 


^2,19 


^2,20 


^2,21 


62,22 


62,23 


62,24 


62,25 


62,26 


62,27 


62,28 


62,29 


^2,30 


^2,31 


^2,32 


^2,33 


^2,34 


^2,35 


^2,36 


^2,37 


62,38 


62,39 


62,40 


62,41 


62,42 


62,43 


62,44 


62,45 


^2,46 


^2,47 


^2,48 


^2,49 


^2,50 


^2,51 


^2,52 


^2,53 


62,54 


62,55 


62,56 


62,57 


62,58 


62,59 


62,60 


62,61 


^2,62 


^2,63 


^2,64 


^2,65 


^2,66 


^2,67 


^2,68 


^2,69 


62,70 


62,71 


62,72 


62,73 


62,74 


62,75 


62,76 


62,77 


^2,78 


^2,79 


^2,80 


^2,81 


^2,82 


^2,83 


^2,84 


^2,85 


62,86 


62,87 


62,88 


62,89 


62,90 


62,91 


62,92 


62,93 


^2,94 


^2,95 


^2,96 


^2,97 


^2,98 


^2,99 


^2,1 00 


^2,101 


62,102 
























Figure 14: Source block consisting of 3 source RTP packets of lengths 26, 52 and 103 bytes. 



8.2.2.8 



FEC scheme definition 



This clause defines a FEC encoding scheme and is identified by the FEC encoding ID [TBA]. It utilized the method for 
forming FEC source block as defined in clause 8.2.1.3. It defines two different FEC payload IDs, one for source RTP 
packets and another for FEC encoding symbols that are used with the corresponding RTP payload formats. 

NOTE: This clause will require some rewording after the final decision on the FEC scheme(s). 
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8.2.2.9 Source FEC Payload ID 

The Source FEC payload ID is composed as follows: 



Source Block Number (SBN) 



Encoding Symbol ID (ESI) 



Source Block Number (SBN), (8 bits or 16 bits): The l-D of the source block the media packet belongs to. 
Encoding Symbol ID (ESI), (8 bits or 16 bits): The starting symbol index of the source packet in the source block. 

Figure 15: Source FEC Payload ID 

NOTE 1 : The Source Block number could be 1 byte or 2 bytes and is independent of the FEC scheme - its length is 
a tradeoff decision between wrap-round resilience and overhead. It would also be possible to allow both 
lengths and distinguish by SDP. This needs to be decided. 

NOTE 2: As far as we understand the 2 FEC proposals, the length of SBN and ESI is as follows: 





Raptor 
codes 


2D Reed- 
Solomon 


SBN 


1 or 2 


1 or 2 


ESI 


2 


1 



8.2.2.10 Repair FEC payload ID 

The structure of the Repair FEC Payload ID is as follows: 



Source Block Number SBN 



Encoding Symbol ID ESI 



Source block length SBL 



Encoding block length EBL 



Symbol Length T 



Source Block Number (SBN), (8 bits or 16 bits): The l-D of the source block the media packet belongs to. 

Encoding Symbol ID (ESI), (8 bits or 16 bits): The starting symbol index of the source packet in the source block. 

Source Block Length (SBL), (8 bits, 16 bits or 32 bits): The number of source symbols in the source block. 

Encoding Block Length (EBL), (not present, 8 bits, 16 bits or 32 bits): The total number of symbols (source 

symbols of the source block plus encoding symbols generated from the source block) that are sent for the source 

block. 

Symbol Length (T), (not present, 8 or 16 bits): The length of a symbol in bytes. 

Figure 16: Repair FEC Payload ID 

NOTE 1 : The rest of this clause requires rewording after the FEC schemes supported have been selected. 

NOTE 2: As far as we understand the 2 FEC proposals, the length of the various FEC payload ID fields is as 
follows: 





Raptor codes 


2D Reed-Solomon 


SBN 


1 or 2 


1 or 2 


ESI 


2 


1 


SBL 


2 


1 


EBL 





1 


T 


2(*) 


1 


NOTE: The (*) denotes fields that could probably be of zero 
length here, and conveyed in SDP. 



8.2.2.1 1 Hypothetical FEC Decoder 

This clause specifies the hypothetical FEC decoder and its use to check packet stream and MBMS receiver 
conformance. 
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The hypothetical FEC decoder uses the packet stream, the transmission time of each packet, the initial buffering delay, 
and the SDP for the stream as inputs. The packet stream from the beginning of the FEC source block until the end of the 
stream shall comply with the hypothetical reference decoder as specified below when the initial buffer delay equals to 
the value of the min-buffer-time MIME parameter. 

The maximum buffer size for MBMS streaming is 1 Mbytes. The default hypothetical FEC decoding buffer size is 
equal to 1 Mbytes. 

For the packet stream, the buffer occupancy level of the hypothetical FEC decoding buffer shall not exceed the value of 
the buf-size MIME parameter, when it is present in the SDP, or the default FEC decoding buffer size, when the buf-size 
MIME parameter is not present in the SDP. The output of the hypothetical FEC decoder shall comply with the RTP 
payload and decoding specifications of the media format. 

The hypothetical FEC decoder operates as follows: 

1) The hypothetical FEC decoding buffer is initially empty. 

2) Each FEC source packet and FEC repair packet, including its RTP header, starting from the first packet in 
transmission order, is inserted to a FEC source block at its transmission time. The FEC source block generation 
is done as specified in clause 8.2.1.6. The FEC source block resides in the hypothetical FEC decoding buffer. 

3) When both the last FEC source packet and the last FEC repair packet of an FEC source block are transmitted, 
any elements of the FEC source block that are not original RTP packets (e.g. FEC repair packets and potential 
padding bytes) are removed from the hypothetical FEC decoding buffer. 

4) Original RTP packets are not removed from the hypothetical FEC decoding buffer before the signaled initial 
buffering delay has expired. Then, the first original RTP packet in sequence number order is output and removed 
from the hypothetical FEC decoding buffer immediately. Each succeeding original RTP packet is output and 
removed when the following conditions are true: 

i. The following time (in seconds) since the removal of the previous packet has elapsed: 

8 X (size of the previous original RTP packet with UDP/IP header overhead in bytes) / (1 000 x (value of 
"b=AS" SDP attribute for the stream)) 

ii. All the packets in the same FEC source block as the original RTP packet have been transmitted. 

An MBMS client shall be capable of receiving a packet stream that complies with the hypothetical FEC decoder. 
Furthermore, when an MBMS client complies with the requirements for the media decoding of the packet stream, it 
shall be able to de-packetize and decode the packet stream and output decoded data at the correct rate specified by the 
RTP timestamps of the received packet stream. 

8.2.2.12 FEC encoding procedures 

NOTE: Here the exact procedures of the FEC scheme is to be defined. A reference to the detailed annex will be 
put when the FEC scheme is decided. 

8.2.2.13 Signalling 

The two different RTP payload formats requires each a media type to identify them and define their respective set of 
parameters. The media types are: 

• media type audio, video, or text/rtp-mbms-fec-repair; 

• media type audio, video, or text/rtp-mbms-fec-source. 
Their associated set of parameters are defined in annex C. 
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8.2.2.14 Mapping the Media types to SDP 

The information carried in the MIME media type specification has a specific mapping to fields in the Session 
Description Protocol (SDP) [6], which is commonly used to describe RTP sessions. When SDP is used to specify 
sessions employing the FEC payload format, the mapping is as follows: 

• The Media type (application, audio, video, or text) goes in SDP "m=" as the media name. 

• The Media subtype (payload format name) goes in SDP "a=rtpmap" as the encoding name. The RTP clock rate 
in "a=rtpmap" SHALL be 10000 for audio/rtp-mbms-fec-repair, video/rtp-mbms-fec -repair, or text/rtp-mbms- 
fec-repair, and according to the rate parameter for audio/rtp-mbms-fec-source, video/rtp-mbms-fec-source, or 
text/rtp-mbms-fec-source. 

• The FEID and FIID parameters are indicated using the "a=FEC-declaration" (see clause 7.3.2.8) and the FOTI 
parameter by the "a=FEC-OTI-extension" (see clause 8.3.1.9). To bind the correct EEC-declaration and 
corresponding FEC-OTI-extension to a payload type, an "a=fmtp" line parameter value pair 
"FEC-ref="<fec-ref> shall be used. Where the <fec-ref> value is equal to the fee -ref number used in the SDP 
attributes EEC -declaration and EEC-OTI-extension. 

• Any remaining parameters go in the SDP "a=fmtp" attribute by copying them directly from the MIME media 
type string as a semicolon separated list of parameter=value pairs. 

These payload formats is only intended to be used in declarative SDP use cases and no offer/answer negotiation 
procedures is defined. 

8.2.2.1 5 Example of SDP for FEC 

An example of how an SDP could look for a session containing two media streams that are EEC protected. In this 
example we have assumed an audiovisual stream, using 56 kbps for video and 12 kbps for audio. We further assume 
that we send redundant packets for the video part at 6 kbps and redundant packets for the audio part at 3 kbps. Hence, 
the total media session bandwidth is 56 H- 6 H- 12 H- 3 = 77 kbps. In addition another 1 200 bits/s of RTCP packets from 
the source is used for the both sessions. 

The EEC encoding symbols payloads does also declare that the minimal required buffering time for either of the 
streams are 2.6 seconds. As the value is defined as a limitation on the sender side, further buffering to handle jitter in 
the transmission is also likely to be required. 

v=0 

o=ghost 2890844526 2890842807 IN IP4 192.168.10.10 

s=3GPP MBMS Streaming SDP Example 

i=Example of MBMS streaming SDP file 

u=http : //www. inf oserver . example . com/ae600 

e=ghost@mailserver . example . com 

C=IN IP4 224.1.2.3 

t=3034423619 3042462419 

b=AS:77 

m=video 4002 RTP/AVP 97 96 100 

b=AS : 62 

b=RR:0 

b=RS:600 

a=rtpmap:96 H263-2000/90000 

a=fmtp:96 prof ile=3; level=10 

a=f ramesize : 96 176-144 

a=rtpmap: 97 rtp-inbms-fec-source/90000 

a=fmtp:97 opt=96; FEID=129;FIID=12435;FOTI="lSCxWEMNe397m24SwgyRhg==" 

a=rtpmap: 100 rtp-mbms-fec-repair/lOOOO 

a=fmtp:100 FEID=129;FIID=12435;FOTI="lSCxWEMNe397m24SwgyRhg==" ; min-buffer-time=2600 

m=audio 4004 RTP/AVP 99 98 101 

b=AS:15 

b=RR:0 

b=RS:600 

a=rtpmap:98 AMR/8000 

a=fmtp:98 octet-align=l 

a=rtpmap: 99 rtp-mbms-fec-source/8000 

a=fmtp: 99 opt=98;FEID=129;FIID=12435;FOTI="lSCxWEMNe397m24SwgyRhg==" 

a=rtpmap: 101 rtp-mbms-fec-repair/lOOOO 

a=fmtp:101 FEID=129;FIID=12435;FOTI="lSCxWEMNe397in24SwgyRhg==" ; min-buffer-time=2600 
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8.3 Session description 

SDP is provided to the MBMS client via a discovery/announcement procedure to describe the streaming delivery 
session. The SDP describes one or more RTF session part of the MBMS streaming session. The SDP shall be a 
correctly formed SDP according to RFC 2327 [14]. 

8.3.1 SDP Parameters for IVIBIVIS streaming session 

The semantics of a Session Description of an MBMS streaming session shall include the parameters: 
The sender IP address. 
The number of media in the session. 

The destination IP address and port number for each and all of the RTP sessions in the MBMS streaming 

session. 

The start time and end time of the session. 

The protocol ID (i.e. RTP/AVP). 

Media type(s) and fmt-list. 

Data rate using existing SDP bandwidth modifiers. 

Mode of MBMS bearer per media. 

FEC configuration and related parameters. 

Service-language(s) per media. 

QoE Metrics (defined in clause 8.3.1.1). 

8.3.1.1 Sender IP address 

There shall be exactly one IP source address per media description within the SDP. The IP source address shall be 
defined according to the source-filter attribute ("a=source-filter:") [15] for both IPv4 and IPv6 sources, with the 
following exceptions: 

1 . Exactly one source address may be specified by this attribute such that exclusive-mode shall not be used and 
inclusive-mode shall use exactly one source address in the <src-list>. 

2. There shall be exactly one source-filter attribute per complete MBMS streaming session SDP description, and 
this shall be in the session part of the session description (i.e. not per media). 

3. The * value shall be used for the <dest-address> subfield. 

8.3.1 .2 Destination IP address and port number for channels 

Each RTP session part of a MBMS streaming session is defined by two parameters: 

• IP destination address. 

• Destination port number(s). 

The IP destination address shall be defined according to the "connection data" field ("c=") of RFC 2327 [14]. The 
destination port number shall be defined according to the <port> sub-field of the media announcement field ("m=") of 
RFC 2327 [14]. Multiple ports using "/" notation shall not be used. The RTCP port, if used, shall be RTP port +1. 
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8.3.1.3 Media Description 

The media description line shall be used as defined in RFC 2327 [14] for RTP. The <media> part indicates the type of 
media, audio, video, or text. The usage of RTP and any applicable RTP profile shall be indicated by using the <proto> 
field of the 'm-line'. The one or more payload types that are being used in this RTP session are enumerated in the <fmt> 
part. Each payload type is declared using the "a=rtpmap" attribute according to RFC 2327 [14] and use the "a=fmtp" 
line when required to describe the payload format parameters. 

8.3.1.4 Session Timing Parameters 

A MBMS streaming session start and end times shall be defined according to the SDP timing field ("t=") - 
RFC 2327 [14]. 

8.3.1 .5 Mode of MBMS bearer per media 

The MBMS bearer mode declaration attribute defined in clause 7.3.2.7 may be used. 

8.3.1 .6 Service-language(s) per media 

The existing SDP attribute "a=lang" is used to label the language of any language-specific media. The values are taken 
from RFC 3066 [73] which in turn takes language and (optionally) country tags from ISO 639 [74] and ISO 3661 [75] 
(e.g. "a=lang:EN-US"). These are the same tags used in the User Service Description XML. 

8.3.1.7 Bandwidth specification 

The bit-rate required by the MBMS streaming session and its media components shall be specified using both the "AS" 
bandwidth modifier and the "TIAS" bandwidth modifier combined with "a=maxprate" [31] on media level in the SDP. 
On session level the "TIAS" bandwidth modifier combined with "a=maxprate" may be used. Where the session level 
expresses the aggregated peak bit-rate, which may be lower than the sum of the individual media streams. 

The bandwidth required for RTCP is specified by the "RR" and "RS" bandwidth modifiers (3GPP TS 26244 [32]) on 
media level for each RTP session. The "RR" modifier shall be included and set to to specify that RTCP receiver 
reports are not used. The bandwidth used for RTCP sender reports shall be specified using the "RS" bandwidth 
modifier. 

8.3.1.8 FEC Parameters 

The FEC encoding ID and instance ID is provided using the "a=FEC-declaration" attribute defined in clause 7.3.2.8. 
Any OTI information for that FEC encoding ID and instance ID is provided with below defined FEC OTI attribute. 

The FEC OTI attribute must be immediately preceded by the "a=FEC-declaration" attribute (and so can be session-level 
and media-level). The fec-ref maps the oti-extension to the EEC-declaration OTI it extends. The purpose of the oti- 
extension is to define FEC code specific OTI required for RTP receiver FEC payload configuration, exact contents are 
FEC code specific and need to be specified by each FEC code using this attribute. 

The syntax for the attributes in RFC 2234 [23] is: 

• sdp-fec-oti-extension-line = "a=FEC-OTI-extension:" fec-ref SP oti-extension CRLF 

• fec-ref = 1*DIGIT (the SDP-intemal identifier for the associated FEC -declaration). 

• oti-extension = base64 

• base64 = *base64-unit [base64-pad] 

• base64-unit = 4base64-char 

• base64-pad = 2base64-char "==" / 3base64-char "=" 

• base64-char = ALPHA / DIGIT / "h-" / "/" 
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The FEC declaration and FEC OTI information utilized in a specific RTP payload type is indicated using the FEC-ref 
number in the a=fmtp lines as described in clause 8.2.1.14. 

8.3.2 SDP Example for Streaming Session 

Here is a full example of SDP description describing a FLUTE session: 

v=0 

o=ghost 2890844526 2890842807 IN IP4 192.168.10.10 

s=3GPP MBMS Streaming SDP Example 

i=Example of MBMS streaming SDP file 

u=http ; //www. inf oserver . example . com/ae600 

e=ghost@mailserver . example . com 

C=IN IP 6 FF1E:03AD: :7F2E:172A:1E24 

t=3034423619 3042462419 

b=AS:77 

a=mbms-mocle ; broadcast 1234 

a=source-filter: incl IN IP6 * 2001 : 210 : 1 : 2 : 240 : 96FF :FE25 : 8EC9 

a=FEC-cleclaration ; encocling-id=130; instance-id=0 

a=FEC-OTI-extension: lSCxWEMNe397m24SwgyRhg== 

a=FEC-declaration: 1 encoding-id=131; instance-id=2 

a=FEC-OTI-extension: 1 lSCxWEMNe397m24SwgyRhg== 

m=video 4002 RTP/AVP 97 96 100 

b=TIAS: 62000 

b=RR:0 

b=RS:600 

a=maxprate ; 17 

a=rtpmap:96 H264/90000 

a=fmtp ; 96 prof ile-level-id=4 2A01E; packet iz at ion-mode = l; sprop-parameter-sets = ZOIACpZTBYmI, aMl jiA== 

a=rtpmap: 97 rtp-mbms-fec-source/90000 

a=fmtp:97 opt=96; FEC-ref=0 

a=rtpmap: 100 rtp-mbms-fec-source/10000 

a=fmtp:100 FEC-ref=l; min-buf fer-time=2600 

m=audio 4004 RTP/AVP 99 98 101 

b=TIAS: 15120 

b=RR:0 

b=RS:600 

a=maxprate ; 10 

a=rtpmap:98 AMR/ 8000 

a=fmtp:98 octet-align=l 

a=rtpmap; 99 rtp-mbms-fec-source/8000 

a=fmtp: 99 opt=98; FEC-ref=0 " 

a=rtpmap : 101 rtp-mbms-fec-source/10000 

a=fmtp:101 FEC-ref=l; min-buf fer-time=2600 

8.3.2.1 SDP Description for QoE Metrics 

Similar to as in 3GPP TS 26.234 [47], an SDP attribute for QoE, which can be used either at session or media level, is 
defined below in RFC 2234 [23] based on RFC 2327 [14]: 

• QoE-Metrics-hne = "a" "=" "3GPP-QoE-Metrics:" att-measure-spec *("," att-measure-spec)) CRLF 

• att-measure-spec = Metrics ";" Sending-rate [";" Measure-Range] *([";" Parameter-Ext]) 

• Metrics = "metrics" "=" "{"Metrics-Name *("," Metrics-Name) " }" 

• Metrics-Name = I*((0x21..0x2b) / (0x2d..0x3a) / (0x3c..0x7a) / 0x7c / 0x7e) ;VCHAR except ";", ",", "{" 

or"}" 

• Sending-Rate = "rate" "=" 1*DIGIT / "End" 

• Measure-Range = "range" "=" Ranges-Specifier 

• Parameter-Ext = (1*DIGIT ["." 1*DIGIT]) / (I*((0x21..0x2b) / (0x2d..0x3a) / (0x3c..0x7a) / 0x7c / 0x7e)) 

• Ranges-Specifier = as defined in RFC 2326 [76]. 

An MBMS server uses this attribute to indicate that QoE metrics are supported and shall be used if also supported by 
the MBMS client. When present at session level, it shall only contain metrics that apply to the complete session. When 
present at media level, it shall only contain metrics that are applicable to individual media. 
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The "Metrics" field contains the list of names that describes the metrics/measurements that are required to be reported in 
a MBMS session (see clause 8.4). The names that are not included in the "Metrics" field shall not be reported during the 
session. 

In this version of the specification, the "Sending-Rate" shall be set to the value "End", which indicates that only one 
report is sent at the end of the MBMS session. 

The optional "Measure-Range" field, if used, shall define the time range in the stream for which the QoE metrics will be 
reported. There shall be only one range per measurement specification. The range format shall be any of the formats 
allowed by the media. If the "Measure-Range" field is not present, the corresponding (media or session level) range 
attribute in SDP shall be used. If SDP information is not present, the metrics range shall be the whole session duration. 

8.4 Quality of Experience 

8.4.1 General 

The MBMS Quality of Experience (QoE) metrics feature is optional for both MBMS streaming server and MBMS 
client, and shall not disturb the MBMS service. An MBMS Server that supports the QoE metrics feature shall activate 
the gathering of client QoE metrics with SDP as described in clause 8.3.1.1 and via the reception reporting procedure as 
described in clause 9.4. An MBMS client supporting the feature shall perform the quality measurements in accordance 
to the measurement definitions, aggregate them into client QoE metrics and report the metrics to the MBMS server 
using the content reception reporting procedure. The way the QoE metrics are processed and made available is out of 
the scope of the present document. 

8.4.2 QoE IVIetrics 

A MBMS client should measure the metrics at the transport layer after EEC decoding (if EEC is used), but may also do 
it at the application layer for better accuracy. 

The reporting period for the metrics is the whole streaming duration. This duration may be less than the session 
duration, because of late joiners or early leavers. The reporting period shall not include any voluntary event that impacts 
the actual play, such as pause, or any buffering or freezes/gaps caused by them. 

The following metrics shall be derived by the MBMS client implementing QoE. All the metrics defined below are only 
applicable to at least one of audio, video, speech and timed text media types, and are not applicable to other media types 
such as synthetic audio, still images, bitmap graphics, vector graphics, and text. Any unknown metrics shall be ignored 
by the client and not included in any QoE report. Among the QoE metrics, corruption duration, successive loss of RTP 
packets, frame-rate deviation and jitter duration are of media level, whereas initial buffering duration and rebuffering 
duration are of session level. 

8.4.2.1 Corruption duration metric 

Corruption duration, M, is the time period from the NPT time of the last good frame before the corruption, to the NPT 
time of the first subsequent good frame or the end of the reporting period (whichever is sooner). A corrupted frame may 
either be an entirely lost frame, or a media frame that has quality degradation and the decoded frame is not the same as 
in error-free decoding. A good frame is a "completely received" frame X that, either: 



• 



it is a refresh frame (does not reference any previously decoded frames AND where none of the subsequent 
received frames reference any frames decoded prior to X); or 



• does not reference any previously decoded frames; or 

• references previously decoded "good frames". 

"Completely received" means that all the bits are received and no bit error has occurred. 

Corruption duration, M, in milliseconds can be calculated as below: 

a) M can be derived by the client using the codec layer, in which case the codec layer signals the decoding of a 
good frame to the client. A good frame could also be derived by error tracking methods, but decoding quality 
evaluation methods shall not be used. 
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b) In the absence of information from the codec layer, M should be derived from the NPT time of the last frame 
before the corruption and N, where N is optionally signalled from MBMS streaming server (via SDP) to the 
MBMS client and represents the maximum duration between two subsequent refresh frames in milliseconds. 

c) In the absence of information from the codec layer and if N is not signalled, then M defaults to °o (for video) or 
to one frame duration (for audio), or the end of the reporting period (whichever is sooner). 

The optional parameter N as defined in point b is used with the "Corruption_Duration" parameter. Another optional 
parameter T is defined to indicate whether the client uses error tracking or not. The value of T shall be set by the client 
via reception reporting (clause 9.5.2) as on or off. The syntax for N to be included in the "att-measure-spec" 
(clause 8.3.1.1) is as follows: 

• N="N" "=" 1*DIGIT 

In MBMS reception reporting will be done only once at the end of streaming, hence all the occurred corruption 
durations are summed up over the period of the stream as the value TotalCorruptionDuration. The unit of this metrics is 
expressed in milliseconds. The number of individual corruption events over the stream duration are summed up in the 
value NumberOfCorruptionEvents. These two values are reported by the MBMS client as part of the reception report 
(clauses 9.4.6 and 9.5.2). 

8.4.2.2 Rebuffering duration metric 

Rebuffering is defined as any stall in playback time due to any involuntary event at the client side. 

The syntax for the metric "Rebuffering_Duration" for the QoE-Feedback header is as defined in clause 8.3.1.1. 

Rebuffering starts at the NPT time of the last played frame before the occurrence of the rebuffering. 

In MBMS reception reporting will be done only once at the end of streaming, hence all the occurred rebuffering 
durations are summed up over the period of the stream as the value TotalRebujferinfDuration. The unit of this metrics is 
expressed in seconds, and can be a fractional value. The number of individual rebuffering events over the stream 
duration are summed up in the value NumberOfRebujferingEvents. These two values are reported by the MBMS client 
as part of the reception report (clauses 9.4.6 and 9.5.2). 

8.4.2.3 Initial buffering duration metric 

Initial buffering duration is the time from receiving the first RTP packet until playing starts. 

The syntax for the "Initial_Buffering_Duration" is as defined in clause 8.3.1.1. 

If the reporting period is shorter than the "Initial_Buffering_Duration" then the MBMS client should send this 
parameter for the reporting period as long as it observes it. The metric value indicates the initial buffering duration 
where the unit of this metrics is expressed in seconds, and can be a fractional value. There can be only one measure and 
it can only take one value. "Initial_Buffering_Duration" is a session level parameter.This value is reported by the 
MBMS client as part of the reception report (clauses 9.4.6 and 9.5.2). 

8.4.2.4 Successive loss of RTP packets 

The metric "Successive_Loss" indicates the number of RTP packets lost in succession (excluding FEC packets) per 
media channel. 

The syntax for the metrics "Successive_Loss" is as defined in clause 8.3.1.1. 

In MBMS reception reporting will be done only once at the end of streaming, hence all the number of successively lost 
RTP packets are summed up over the period of the stream as the value TotalNumberofSuccessivePacketLoss. The unit 
of this metric is expressed as an integer equal to or larger than 1 . The number of individual events over the stream 
duration are summed up in the value NumberOfSuccessiveLossEvents. These two values are reported by the MBMS 
client as part of the reception report (clauses 9.4.6 and 9.5.2). 

8.4.2.5 Frame rate deviation 

Frame rate deviation indicates the playback frame rate information. Frame rate deviation happens when the actual 
playback frame rate during a reporting period is deviated from a pre-defined value. 
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The actual playback frame rate is equal to the number of frames played during the reporting period divided by the time 
duration, in seconds, of the reporting period. 

The parameter FR that denotes the pre-defined frame rate value is used with the "Framerate_Deviation" parameter in 
the "3GPP-QoE-Metrics" attribute. The value of FR shall be set by the server. The syntax for FR to be included in the 
"att-measure-spec" (clause 8.3.1.1) is as follows: 

• FR = "FR" "=" 1*DIGIT "." 1*DIGIT 

The syntax for the metric "Framerate_Deviation" is defined in clause 8.3.1.1. 

For the Metrics-Name "Framerate_Deviation", the value field indicates the frame rate deviation value that is equal to 
the pre-defmed frame rate minus the actual playback frame rate. This metric is expressed in frames per second, and can 
be a fractional value, and can be negative. This value is reported by the MBMS client as part of the reception report 
(clauses 9.4.6 and 9.5.2). 

8.4.2.6 Jitter duration 

Jitter happens when the absolute difference between the actual playback time and the expected playback time is larger 
than a pre-defmed value, which is 100 milliseconds. The expected time of a frame is equal to the actual playback time 
of the last played frame plus the difference between the NPT time of the frame and the NPT time of the last played 
frame. 

The syntax for the metric "Jitter_Duration" is defined in clause 8.3.1.1. 

In MBMS reception reporting will be done only once at the end of streaming, hence all the Jitter_Durations are summed 
up over the period of the stream as the value TotalJitterDuration. The unit of this metrics is expressed in seconds, and 
can be a fractional value. The number of individual events over the stream duration are summed up in the value 
NumberOfJitterEvents. These two values are reported by the MBMS client as part of the reception report (clauses 9.4.6 
and 9.5.2). 



8.4.3 Example metrics initiation with SDP 



This following example shows the syntax of the SDP attribute for QoE metrics. The session level QoE metrics 
description (Initial buffering duration and rebufferings) are to be monitored and reported only once at the end of the 
session. Also video specific description of metrics (corruptions) are to be monitored and reported at the end from the 
beginning of the stream until the time 40s. Finally, audio specific description of metrics (corruptions) is to be monitored 
and reported at the end from the beginning until the end of the stream. 

SDP example: 

v=0 

o=- 3268077682 433392265 IN IP4 63.108.142.6 

s=QoE Enables Session Description Example 

e=support@f oo . com 

c=IN IP4 0.0.0.0 

t=0 

a=range:npt=0-83. 660000 

a=3GPP-QoE-Metrics ; ( Initial_Buf f ering_Duration, Rebuf f ering_Duration} ; rate=Encl 

a=control : * 

m=video RTP/AVP 96 

b=AS : 2 8 

a=3GPP-QoE-Metrics ; ( Corruption_Duration} ; rate=Encl; range: npt = 0-4 

a=control;trackID=3 

a=rtpmap:96 MP4V-ES/1000 

a=range:npt=0-83. 666000 

a=fmtp: 96prof ile-level-id=8; config=000001bOO 800000 IbSO 9000 12000 

m=audio RTP/AVP 98 

b=AS:13 

a=3GPP-QoE-Metrics : {Corruption_Duration} ; rate=End 

a=control;trackID=5 

a=rtpmap:98 AMR/ 80 00 

a=range:npt=0-83. 660000 

a=fmtp:98 octet-align=l 

a=maxpt ime : 2 
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Associated delivery procedures 



9.1 Introduction 

Associated delivery procedures describe general procedures, which start before, during or after the MBMS data 
transmission phase. They provide auxiliary features to MBMS user services in addition, and in association with, 
MBMS delivery methods and their sessions. Those procedures that shall only be permitted after the MBMS Data 
transmission phase may also be described as post-delivery procedures. 

To enable future backwards compatibility beyond 3GPP MBMS release 6 specifications, clause 9specifies generic and 
extensible techniques for a potentially wide range of associated delivery procedures. 

Clauses 9.3 and 9.4 the associated delivery procedures that are included in release 6, and are initiated only after an 
MBMS data transmission phase. 

The present document describes these associated delivery procedures: 

• File repair, for post-delivery repair of files initially delivered as part of an MBMS download session. 

• Content reception reporting of files delivered to an MBMS UE. 

These procedures are enabled by establishing a point-to-point connection; and using the MBMS session parameters, 
received during User Service Discovery/ Announcement, to communicate the context (e.g. file and session in question) 
to the network and the MBMS sender infrastructure. To avoid network congestion in the uplink and downlink 
directions, and also to protect servers against overload situations, the associated delivery procedures from different 
MBMS UEs shall be distributed over time and resources (network elements). 

An instance of an "associated procedure description" is an XML file that describes the configuration parameters of one 
or more associated delivery procedures. 

When using a download delivery session to deliver download content, the UE shall support the file repair procedure. 

9.2 Associated Procedure Description 

An associated procedure description instance (configuration file) for the associated delivery procedures may be 
deUvered to the MBMS clients: 

• during a User Service Discovery / Announcement prior to the MBMS Download delivery session along with the 
session description (out-of-band of that session); or 

• in-band within a MBMS Download delivery session. 

The most recently delivered configuration file (i.e. the one with the highest version number - as given from the 
envelope, see clause 5.2.3.3) shall take priority, such that configuration parameters received prior to, and out-of-band 
of, the download session they apply to are regarded as "initial defaults", and configuration parameters received during, 
and in-band with the download session, overwrite the earlier received parameters. Thus, a method to update parameters 
dynamically on a short time-scale is provided but, as would be desirable where dynamics are minimal, is not mandatory. 

During the User Service Discovery / Announcement Procedure, the associated procedure description instance is clearly 
identified using a URI, to enable UE cross-referencing of in and out-of-band configuration files. 

The MIME application type "application/mbms-associated-procedure-parameter" identifies associated delivery 
procedure description instances (configuration files). 

In XML, each associated delivery procedure entry shall be configured using an "associatedProcedureDescription" 
element. All configuration parameters of one associated delivery procedure are contained as attributes of an 

"associatedProcedureDescription" element. The elements (e.g. "postFileRepair" and "postReceptionReport") of 

an "associatedProcedureDescription" element identify which associated procedure(s) to configure.. The associated 
delivery procedure description is specified formally as an XML schema in clause 9.5.1. 
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9.3 File Repair Procedure 

9.3.1 Introduction 

The purpose of the File Repair Procedure is to repair lost or corrupted file fragments from the MBMS download data 
transmission. When in multicast/broadcast environment, scalability becomes an important issue as the number of 
MBMS clients grows. Three problems must generally be avoided: 

• Feedback implosion due to a large number of MBMS clients requesting simultaneous file repairs. This would 
congest the uplink network channel. 

• Downlink network channel congestion to transport the repair data, as a consequence of the simultaneous clients 
requests. 

• File repair server overload, caused again by the incoming and outgoing traffic due to the clients' requests arriving 
at the server, and the server responses to serve these repair requests. 

The three problems are interrelated and must be addressed at the same time, in order to guarantee a scalable and 
efficient solution for MBMS file repair. 

The principle to protect network resources is to spread the file repair request load in time and across multiple servers. 

The MBMS chent: 

1 . Identifies the end of transmission of files or sessions. 

2. Identifies the missing data from an MBMS download. 

3. Calculates a random back-off time and selects a file repair server randomly out of a list. 

4. Sends a repair request message to the selected file repair server at the calculated time. 

When a MBMS download session of repair data is configured in the associated delivery descriptions, a MBMS client 
should wait for repair data in the defined MBMS download session on its MBMS bearer - except where the UE is 
prevented from doing so due to limited simultaneous context activation capability. 

Then the file repair server: 

1. Responds with a repair response message either containing the requested data, redirecting the client to an 
MBMS download session, redirecting the client to another server, or alternatively, describing an error case. 

The BM-SC may also send the repair data on a MBMS bearer (possibly the same MBMS bearer as the original 
download) as a function of the repair process. 

The random distribution, in time, of repair request messages enhances system scalability to the total number of such 
messages the system can handle without failure. 

9.3.2 Identification of End of Transmission for MBMS Download Delivery 

FLUTE File Delivery Table (FDT) Instances include an "expires" attribute, which defines the expiration time of the 
FDT instance. The sender must use an expiry time relative to its sender current time. The Sender Current Time header 
field shall be present in all FLUTE packets containing data of an FDT Instance. According to RFC 3926 [9], "the 
receiver SHOULD NOT use a received FDT Instance to interpret packets received beyond the expiration time of the 
FDT Instance". 

The MBMS UE determines the end-of-transmission for the MBMS download delivery based on the expiration time of 
the FDT instance and any end-of-object (B-flag) and end-of-session (A-flag, and SDP end time) information available. 

When a particular file (URI) is present in several FDT Instances with different TOI values, then the expiration time of 
the FDT Instances, which contain the highest TOI value of that file determines the end of transmission time for that file. 
A UE shall only determine transmission completeness for a file for the most up-to-date instance of the file (the file 
instance/version with the highest/most-up-to-date TOI) - and shall not use FDT Instance expiry time to determine 
transmission completeness for any other (TOI) instances of a file (fileURJ). 
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NOTE 1 : The intention of this clause is to just start the Associated Delivery Procedure back-off timer for the latest 
version of a file. 

When a particular file (URI) is present in more than one FDT Instance with the same TOI value, then the end of 
transmission time is defined by the expiration time of the last FDT Instance to expire. 

If an FDT Instance is received describing the file after this time (giving an FDT Instance expiry time in the future and 
the same or a higher TOI value) the UE shall determine that the transmission of the file is incomplete - i.e. that more 
packets may arrive by the MBMS download session for that file, Torgetting' its previous file transmission complete 
determination. 

NOTE 2: This effectively resets and stops any running timers already initiated for an associated delivery procedure 
for that file. 

If the MBMS UE receives an end-of-object packet (with FLUTE header B flag set true) the MBMS UE shall determine 
that the transmission of that object is complete, and shall interpret that as file transmission complete if no, more recent, 
TOIs are described for the same file (URI) in any received and unexpired FDT Instance(s). 

If the MBMS UE determines that the download session is complete (as specified in clause 9.4.2) then it shall interpret 
this also that all the transmissions of all files (and TOIs) described by all FDT Instances, received from that session, are 
complete. 

9.3.3 Identification of Missing Data from an MBMS Download 

The session description and (in-band) the MBMS download delivery protocol, FLUTE, provide the client with 
sufficient information to determine the source block and encoding symbol structure of each file. From this a client is 
able to determine which source (not redundant EEC) symbols should have been transmitted but have not been received. 
The client is also able to determine the number of symbols it has received for each determined source block of each file, 
and, in the case that a fixed EEC code rate (source:redundant symbol ratio) is communicated, exactly which redundant 
(parity) symbols it has not received which should have been sent. 

Thus, an MBMS client is able to identify any source symbols lost in transmission, any redundant symbols where the 
EEC ration is communicated, and the number (and ESI values where appropriate) of required source and redundant 
symbols that would complete the reconstruction of a source block (of a file). 

9.3.4 Back-off Timing the Procedure Initiation Messaging for Scalability 

This clause describes a back-off mode for MBMS download to provide information on when a receiver, that did not 
correctly receive some data from the MBMS sender during a transmission session, can start a request for a repair 
session. In the following it is specified how the information and method a MBMS client uses to calculate a time 
(back-off time), instance of the back-off mode, to send a file repair message to the MBMS server. 

The back-off mode is represented by a back-off unit, a back-off value, and a back-off window. The two latter parameters 
describe the back-off time used by the MBMS client. 

The back-off unit (in the time dimension) defaults to seconds and it is not signalled. 

The back-off time shall be given by an offset time (describing the back-off value) and a random time period (describing 
the back-off window) as described in the following clauses. 

An MBMS client shall generate random or pseudo-random time dispersion of repair requests to be sent from the 
receiver (MBMS client) to the sender (MBMS server). In this way, the repair request is delayed by a pre-determined 
(random) amount of time. 

The back-off timing of repair request messages (i.e. delaying the sending of repair requests at the receiver) enhances 
system scalability to the total number of such messages the system can handle without failure. 

9.3.4.1 Offset time 

The OffsetTime refers to the repair request suppression time to wait before requesting repair, or in other words, it is the 
time that a MBMS client shall wait after the end of the MBMS data transmission to start the file repair procedure. An 
associated procedure description instance shall specify the wait time (expressed in back-off unit) using the "offset-time" 
attribute. 
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9.3.4.2 Random Time Period 

The Random Time Period refers to the time window length over which a MBMS client shall calculate a random time for 
the initiation of the file repair procedure. The method provides for statistically uniform distribution over a relevant 
period of time. An associated procedure description instance shall specify the wait time (expressed in back-off unit) 
using the "random-time-period" attribute. 

The MBMS client shall calculate a uniformly distributed Random Time out of the interval between and Random Time 
Period. 

9.3.4.3 Back-off Time 

The sending of the file repair request message shall start at Back-off Time = offset-time -n Random Time, and this 
calculated time shall be a relative time after the MBMS data transmission. The MBMS client shall not start sending the 
repair request message before this calculated time has elapsed after the initial transmission ends. 

9.3.4.4 Reset of the Back-off Timer 

The reception of an updated (higher version number) associatedDeliveryProcedureDescription and/or an updated 
sessionDescription shall overwrite the timer parameters used in the back-off algorithm. Except in the case that the 
offset-time, random-time -period and session end time parameters are identical to the earlier version; the back-off time 
shall be recalculated. For currently running timers this requires a reset. 

9.3.5 File Repair Server Selection 

9.3.5.1 List of Server URIs 

A list of file repair servers is provided by a list of server URIs as attributes of the Associated Delivery procedure 
description. These attributes and elements specify URIs of the file repair servers. Server URIs may also be given as IP 
addresses, which may be used to avoid a requirement for DNS messaging. The file repair server URIs of a single 
associated delivery procedure description shall be of the same type, e.g. all IP addresses of the same version, or all 
domain names. The number of URIs is determined by the number of "serverURI" elements, each of which shall be a 
child-element of the "procedure" element. The "serverURI" element provides the references to the file repair server via 
the "xsianyURI" value. At least one "serverURI" element shall be present. 

9.3.5.2 Selection from the Server URI List 

The MBMS client randomly selects one of the server URIs from the list, with uniform distribution. 

9.3.6 File Repair Request Message 

Once missing file data is identified, the MBMS client sends one or more messages to a file repair server requesting 
transmission of data that allows recovery of missing file data. All file repair requests and repair responses for a 
particular MBMS transmission shall take place in a single TCP session using the HTTP protocol (RFC 2616 [18]). The 
repair request is routed to the file repair server IP address resolved from the selected "serverURI". 

The timing of the opening of the TCP connection to the server, and the first repair request, of a particular MBMS client 
is randomized over a time window as described in clause 9.3.2. If there is more than one repair request to be made these 
are sent immediately after the first. 

When a MBMS client identifies symbols in repair requests these shall be source symbols, and should include all the 
missing source symbols of the relevant source block. Note, these represent information for the file repair server and the 
BM-SC may use these and/or redundant symbols in providing the necessary repair data. 

9.3.6.1 File Repair Request Message Format 

After the MBMS download session, the receiver identifies a set of FLUTE encoding symbols which allows recovery of 
the missing file data and requests for their transmission in a file repair session. Each missing packet is uniquely 
identified by the encoding symbol combination (URI, SBN, ESI). 
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The file repair request shall include the URI of the file for which it is requesting the repair data. URI is required to 
uniquely identify the file (resource) and is found from the download delivery method (the FLUTE FDT Instances 
describe file URIs). The (SBN, ESI) pair uniquely identifies a FLUTE encoding symbol which allows recovery of 
missing file data belonging to the above-mentioned file. For completely missed files, a Repair Request may give only 
the URI of the file. 

The client makes a file repair request using the HTTP (RFC 2616 [18]) request method GET. The (SBN, ESI) of 
requested encoding symbols are URL-encoded (RFC 1738 [19]) and included in the HTTP GET request. 

For example, assume that in a FLUTE session a 3gp file with URI = www.example.com/news/latest.3gp was delivered 
to an MBMS client. After the FLUTE session, the MBMS client recognized that it did not receive two packets with 
SBN = 5, ESI = 12 and SBN=20, ESI = 27. Then the HTTP GET request is as follows: 

GET www.example.com/news/latest.3gp?mbms-rel6-FLUTE-repair&SBN=5;ESI=12H-SBN=20;ESI=27 
HTTP/1.1 

A file repair session shall be used to recover the missing file data from a single MBMS download session only. If more 
than one file were downloaded in a particular MBMS download session, and, if the MBMS client needs repair data for 
more than one file received in that session, the MBMS client shall send separate HTTP GET requests for each file. 

An HTTP client implementation might limit the length of the URL to a finite value, for example 256 bytes. In the case 
that the length of the URL-encoded (SBN, ESI) data exceeds this limit, the MBMS client shall distribute the 
URL-encoded data into multiple HTTP GET requests. 

In any case, all the HTTP GETs of a single file repair session shall be performed within a single TCP session and they 
shall be performed immediately one after the other. 

In the following, we give the details of the syntax used for the above request method in ABNF. 

In this case an HTTP GET with a normal query shall be used to request the missing data. 

The general HTTP URI syntax is as follows RFC 2616 [18]: 

• http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] 
Where, for MBMS File Repair Request: 

• query = application "&" [ sbn_info ] 

• application = "mbms-rel6-flute-repair" 

• sbnjnfo = "SBN=" sbn_range *( "+" sbn_range ) 

• sbn_range = ( sbnA [ "-" sbnZ ] ) / ( sbnA [ ";" esijnfo] ) 

• esi_info = ( "ESI=" esi_range *( "," esi_range ) ) 

• esi_range = esiA [ "-" esiZ ] 

• sbnA = 1 *DIGIT; the SBN, or the first of a range of SBNs 

• sbnZ = 1 *DIGIT; the last SBN of a range of SBNs 

• esiA = 1 *DIGIT; the ESI, or the first of a range of SBNs 

• esiZ = 1 *DIGIT; the last ESI of a range of SBNs 

Thus, the following symbols adopt a special meaning for MBMS FLUTE: ? - H- , ; & = 

One example of a query on encoding symbol 34 of source block 12 of a music file "numberl.aac" is: 

• http://www.operator.com/greatmusic/numberl. aac?mbms-rel6-flute-repair&SBN=12;ESI=34 
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For messaging efficiency, the formal definition enables several contiguous and non-contiguous ranges to be expressed 
in a single query: 

• A symbol of a source block (like in the above example). 

• A range of symbols for a certain source block (e.g. ...&SBN=12;ESI=23-28). 

• A list of symbols for a certain source block (e.g. ...&SBN=12;ESI=23,26,28). 

• All symbols of a source block (e.g. ...&SBN=12). 

• All symbols of a range of source blocks (e.g. ...&SBN=12-19). 

• non-contiguous ranges (e.g.l. ...&SBN=12;ES1=34h-SBN=20;ESI=23 also, 
e.g. 2. ...&SBN=12-19h-SBN=28;ESI=23-59h-SBN=30;ESI=101). 

9.3.7 File Repair Response Message 

Once the MBMS file repair server has assembled a set of encoding symbols that contain sufficient data to allow the UE 
to reconstruct the file data from a particular file repair request, the MBMS file repair server sends one message to the 
UE. Each file repair response occurs in the same TCP and HTTP session as the repair request that initiated it. 

An MBMS client shall be prepared for any of these 4 response scenarios: 

• The server returns a repair response message where a set of encoding symbols forms an HTTP payload as 
specified below. 

• The server redirects the client to a broadcast/multicast delivery (an MBMS download session). 

• The server redirects the client to another file repair server (if a server is functioning correctly but is temporarily 
overloaded). 

• An HTTP error code is returned (note that clause 9.3.6 describes the case of no server response). 

For (reasonably) uniformly distributed random data losses, immediate point-to-point HTTP delivery of the repair data 
will generally be suitable for all clients. However, broadcast/multicast delivery of the requested data may be desirable in 
some cases: 

• A repeat MBMS download (all or part of the files from a download session) is already scheduled and the BM-SC 
prefers to handle repairs after that repeat MBMS download. 

• Many UEs request download data (over a short period of time) indicating that broadcast/multicast delivery of the 
repaired data would be desirable. 

In this case a redirect to the broadcast/multicast repair session for UEs that have made a repair request would be 
advantageous. 

9.3.7.1 File Repair Response Messages Codes 

In the case that the file repair server receives a correctly formatted repair request which it is able to understand and 
properly respond to with the appropriate repair data, the file repair server shall attempt to serve that request without an 
error case. 

For a direct point-to-point HTTP response with the requested data, the file response message shall report a 200 OK 
status code and the file repair response message shall consist of HTTP header and file repair response payload (HTTP 
payload), as defined in clause 9.3.5.2. If the client receives a 200 OK response with fewer than all the quantity of 
requested symbols it shall assume that the file repair server wishes the missing symbols to be requested again (due to its 
choice or inability to deliver those symbols with this HTTP response). 

For a redirect case the file repair server uses the HTTP response status code 302 (Found - Redirection) to indicate to the 
UE that the resource (file repair data) is temporarily available via a different URL The temporary URI is given by the 
Location field in the HTTP response. In the case of a redirect to another file repair server, this temporary URI shall be 
the URL of that repair server. 
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In the case of a redirect to a broadcast/multicast delivery, the temporary URI shall be the URI of the Session 
Description (SDP file) of the broadcast/multicast (repair) session as described in clause 9.3.5.3.0ther HTTP status 
codes (RFC 2616 [18]) shall be used to support other cases. Other cases may include server errors, client errors (in the 
file repair request message) and server overload. 

9.3.7.2 File Repair Response Message Format for HTTP Carriage of Repair Data 

The file repair response message consists of HTTP header and file repair response payload (HTTP payload). 
The HTTP header shall provide: 

• HTTP status code, set to 200 OK. 

• Content type of the HTTP payload (see below). 

• Content transfer encoding, set to binary. 

The Content-Type shall be set to "application/simpleSymbolContainer", which denotes that the message body is a 
simple container of encoding symbols as described below. 

This header is as follows: 

• HTTP/1.1 200 OK 

• Content-Type: application/simpleSymbolContainer 

• Content-Transfer-Encoding: binary 

NOTE: Other HTTP headers (RFC 2616 [18]) may also be used but are not mandated by this mechanism. 

Each encoding symbol of the file repair response payload shall be preceded by its EEC Payload ID. The EEC Payload 
ID is specified in below. The file repair response payload is constructed by including each EEC Payload ID and 
Encoding Symbol pair one after another (these are already byte aligned). The order of these pairs in the repair response 
payload may be in order of increasing SBN, and then increasing ESI, value; however no particular order is mandated. 

A single HTTP repair response message shall contain, at the most, the same number of symbols as requested by the 
respective HTTP repair request message. 

The UE and file repair server already have sufficient information to calculate the length of each encoding symbol and 
each EEC Payload ID. All encoding symbols are the same length; with the exception of the last source encoding symbol 
of the last source block where symmetric EEC instance is used. All EEC Payload IDs are the same length for one file 
repair request-response as a single EEC Instance is used for a single file. 

The EEC Payload ID shall consist of the encoding symbol SBN and ESI in big-endian order, with SBN occupying the 
most significant portion. The length, in bytes, of SBN and ESI field are specified by EEC Instance (or EEC Encoding 
and Instance combination) as, for example, in EEC Encoding ID (RFC 3695 [13]) for compact no-code EEC. 

Figure 17 exemplifies the construction of the EEC Payload ID in the case of EEC Encoding ID 0. 

12 3 

01234567890123456789012345678901 

I Source Block Number | Encoding Symbol ID | 

Figure 17: Example FEC Payload ID Format 

Figure 18 illustrates the complete file repair response message format (box sizes are not indicative of the relative 
lengths of the labelled entities). 
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FEC Payload ID n 
(SBN, ESI) 
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9.3.7.3 



Figure 18: File Repair Response IVIessage Format 



File Repair Response for Broadcast/Multicast of Repair Data 



Details of how a file repair server decides, or is instructed, to use broadcast/multicast repair instead of point-to-point 
over HTTP are implementation specific and beyond the scope of the present document. 

Prior to the decision to use broadcast/multicast repair, each repair response shall be provided by HTTP according to 
clause 9.3.5.2. 

The file repair server uses the HTTP response status code 302 (Found - Redirection) to indicate to the UE that the 
resource (file repair data) is temporarily available via a different URL The temporary URI is given by the Location field 
in the HTTP response and is the URI of the Session Description (SDP file) of the broadcast/multicast repair session. 

Where feasible, it is recommended that the same download session that delivered the original data use used for the 
broadcast/multicast repair. If this conflicts with the session end time limit of the Session Description then a new version 
of the Session Description shall be sent with an updated (extended) session end time. This shall be sent in-band of that 
download session. 

In some cases this may not be feasible and an different (possibly new) download session may be defined for the repair. 

The SDP file for broadcast/multicast repair session may be carried as payload (entity-body) in the HTTP response - 
which is especially useful if the broadcast/multicast repair session is a new (or recently end time modified) FLUTE 
download session and other means of service announcement prior to this were not feasible. 

The delivery method's associatedDeliveryProcedureDescription may be updated and the new version transmitted in- 
band with the download session so that currently active client back-off timers are reset, thus minimizing additional 
client requests until after the broadcast/multicast repair session. The server shall be prepared for additional requests in 
any case as successful reception of the updated associatedDeliveryProcedureDescription can not be assured in all cases. 

The existence of a broadcast/multicast file repair session is signalled by the inclusion of the optional bmFileRepair 
procedure in the updated Associated Delivery procedure description. This is signalled by the bmFileRepair element 
with a single "sessionDescriptionURI" attribute of type "xs:anyURI" which specifies the URI of the broadcast/multicast 
file repair session's session description. 

In the cases where the same IP addressing is used for the broadcast/multicast repair session as the original download 
session, the UE simply shall not leave the group. Otherwise, the UE shall join to the MBMS bearer for the repair 
session as it would for any MBMS session. 

A broadcast/multicast file repair session behaves just as an MBMS download session, and the determination of end of 
files and session, and use of further associated delivery procedures uses the same techniques as specified for the MBMS 
download delivery method. 
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9.3.8 Server Not Responding Error Case 



In the error case where a UE determines that the its selected file repair server is not responding it shall return to the 
serverURI list of repair servers and uniformly randomly select another server from the list, excluding any servers it has 
determined are not responding. All the repair requests message(s) from that UE shall then be immediately sent to the 
newly selected file repair server. 

If all of the repair servers from the serverURI list are determined to be not responding, the UE may attempt an HTTP 
GET to retrieve a, potentially new, instance of the session's Associated Procedure Description; otherwise UE behaviour 
in this case is unspecified. 

A UE determines that a file repair server is not responding if any of these conditions apply: 

1 . The UE is unable to establish a TCP connection to the server. 

2. The server does not respond to any of the HTTP repair requests that have been sent by the UE (it is possible that 
second and subsequent repair requests are sent before the first repair request is determined to be 
not-responded-to). 

3. The server returns an unrecognized message (not a recognizable HTTP response). 
The server returns an HTTP server error status code (in the range 500 to 505). 

9.4 The Reception Reporting Procedure 

Following successful reception of content whether through point-to-multipoint MBMS bearers only or using both point- 
to-multipoint and point-to-point bearers, a reception reporting procedure can be initiated by the MBMS Receiver (UE) 
to the BM-SC. 

For MBMS Download Delivery method, the reception reporting procedure is used to report the complete reception of 
one or more files. For MBMS Streaming Delivery method, the reception reporting procedure is used to report statistics 
on the stream. 

If the BM-SC provided parameters requiring reception reporting confirmation then the MBMS Receiver shall confirm 
the content reception. 

If reception reporting is requested for statistical purposes the BM-SC may specify the percentage subset of MBMS 
receivers it would like to perform reception reporting. 

Transport errors can prevent an MBMS Receiver from deterministically discovering whether the reception reporting 
associated delivery procedure is described for a session, and even if this is successful whether a sample percentage is 
described. An MBMS Receiver shall behave according to the information it has even when it is aware that this may be 
incomplete. 

The MBMS Receiver: 

1. Identifies the complete reception of a content item (e.g. a file). See clauses 9.4. land 9.4.2. 

2. Determines the need to report reception. See clause 9.4.3. 

3. Selects a time (Request time) at which a reception report request will be sent and selects a server from a list - 
both randomly and uniformly distributed. See clause 9.4.4 and 9.4.5. 

4. Sends a reception report request message to the selected server at the selected time. See clause 9.4.6. 

Then the server: 

1 . Responds with a reception report response message either containing the requested data, or alternatively, 
describing an error case. See clause 9.4.7. 
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9.4.1 Identifying Complete File Reception from MBMS Download 

A file is determined to be completely downloaded when it is fully received and reconstructed by MBMS reception with 
FEC decoding (if FEC is actually used) and/or a subsequent File Repair Procedure (clause 9.3). The purpose of 
determining file download completeness is to determine when it is feasible for a UE to compile the RAck reception 
report for that file. 

9.4.2 Identifying Complete MBMS Delivery Session Reception 

Delivery sessions (download and streaming) are considered complete when the "time to" value of the session 
description (from "t=" in SDP) is reached. Where the end time is unbounded (time to = 0) then this parameter is not 
used for identifying completed sessions. 

Delivery sessions are also considered complete when the UE decides to exit the session - where no further data from 
that session will be received. In this case the UE may or may not deactivate the MBMS bearer(s). 

For MBMS download sessions, FLUTE provides a "Close session flag" (see clause 7.2.6) which, when used, indicates 
to the UE that the session is complete. 

9.4.3 Determining Whether a Reception Report Is Required 

Upon full reception of a content item or when a session is complete, the MBMS Receiver must determine whether a 
reception report is required. An Associated Delivery Procedure Description indicates the parameters of a reception 
reporting procedure (which is transported using the same methods as the ones that describe File Repair). 

A delivery method may associate zero or one associated delivery procedure descriptions with an MBMS delivery 
session. Where an associated delivery procedure description is associated with a session, and the description includes a 
postReceptionReport element, the UE shall initiate a reception reporting procedure. Reception reporting behaviour 
depends on the parameters given in the description as explained below. 

The Reception Reporting Procedure is initiated if: 

a. A postReceptionReport element is present in the associated procedure description instance. 
One of the following will determine the UE behaviour: 

b. reportType is set to RAck (Reception Acknowledgement). Only successful file reception is reported without 
reception details. 

c. reportType is set to StaR (Statistical Reporting for successful reception). Successful file reception is reported (as 
with RAck) with reception details for statistical analysis in the network. 

d. reportType is set to StaR-all (Statistical Reporting for all content reception). The same as StaR with the addition 
that failed reception is also reported. StaR-all is relevant to both streaming and download delivery. 

The reportType attribute is optional and behaviour shall default to RAck when it is not present. 

The samplePercentage attribute can be used to set a percentage sample of receivers which should report reception. This 
can be useful for statistical data analysis of large populations while increasing scalability due to reduced total uplink 
signalling. The samplePercentage takes on a value between and 100, including the use of decimals. This attribute is of 
a string type and it is recommended that no more than 3 digits follow a decimal point (e.g. 67.323 is sufficient 
precision). 

The samplePercentage attribute is optional and behaviour shall default to 100 (%) when it is not present. The 
samplePercentage attribute may be used with StaR and StaR-all, but shall not be used with RAck. 

When the samplePercentage is not present or its value is 100 each UE which entered the associated session shall send a 
reception report. If the samplePercentage were provided for reportType StaR and StaR-all and the value is less than 
100, the UE generates a random number which is uniformly distributed in the range of to 100. The UE sends the 
reception report when the generated random number is of a lower value than samplePercentage value. 
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9.4.4 Request Time Selection 

The MBMS receiver selects a time at which it is to issue a dehvery confirmation request. 

Back-off timing is used to spread the load of delivery confirmation requests and responses over time. 

Back-off timing is performed according to the procedure described in clause 9.3.2.3. The offsetTime and 
randomTimePeriod used for delivery confirmation may have different values from those used for file-repair and are 
signalled separately in the delivery confirmation associated procedure description instance. 

In general, reception reporting procedures may be less time critical than file repair procedures. Thus, if a postFileRepair 
timer may expire earlier than a postReceptionReport, radio and signalling resources may be saved by using the file 
repair point-to-point PDP context (and radio bearer) activate period also for reception reporting (to remove the delay 
and signalling of multiple activations and deactivations over time) 

The default behaviour is that a UE shall stop its postFileRepair timers which are active when a postFileRepair timer 
expires and results in the successful initiation of point-to-point communications between UE and BM-SC. 

In some circumstances, the system bottleneck may be in the server handling of reception reporting. In this case the 
forceTimelndependence attribute may be used and set to true, (false is the default case and would be a redundant use of 
this optional attribute). "When forceTimelndependence is true the UE shall not use file repair point-to-point connections 
to send reception reporting messages. Instead it will allow the times to expire and initiate point-to-point connections 
dedicated to reception report messaging. 

For StaR and StaR-all, session completeness - according to clause 9.4.2 - shall determine the back-off timer 
initialization time. 

For RAck, the complete download session - according to clause 9.4.2 - as well as completing any associated file repair 
delivery procedure shall determine the back-off timer initialization time. RAcks shall be only sent for completely 
received files according to clause 9.4.1. 

9.4.5 Reception Report Server Selection 

Reception report server selection is performed according to the procedure described in clause 9.3.3.2. 

9.4.6 Reception Report Message 

Once the need for reception reporting has been established, the MBMS receiver sends one or more Reception Report 
messages to the BM-SC. All Reception Report request and responses for a particular MBMS transmission should take 
place in a single TCP session using the HTTP protocol (RFC 2616 [18]). 

The Reception Report request shall include the URI of the file for which delivery is being confirmed. URI is required to 
uniquely identify the file (resource). 

The client shall make a Reception Report request using the HTTP (RFC 2616 [18]) POST request carrying XML 
formatted metadata for each reported received content (file). An HTTP session shall be used to confirm the successful 
delivery of a single file. If more than one file were downloaded in a particular MBMS download multiple descriptions 
shall be added in a single POST request. 

Each Reception Report is formatted in XML according the following XML schema (clause 9.5.2). An informative 
example of a single reception report XML object is also given (clause 9.5.2.2). 

Multipart MIME (multipart/mixed) may be used to aggregate several small XML files of reception reports to a larger 
object. 

For Reception Acknowledgement (RAck) a receptionAcknowledgement element shall provide the relevant data. 

For Statistical Reporting (StaR) a statisticalReporting element shall provide the relevant data. 

For both RAck and StaR/StaR-all (mandatory): 

• For download, one or more fdellRI elements shall specify the list of files which are reported. 
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For only StaR/StaR-all (all optional): 

• Each /;7ef/R/ element has an optional receptionSuccess status code attribute which defaults to "true" ("1") when 
not used. This attribute shall be used for StaR-all reports. This attribute shall not be used for StaR reports. 

• Each QoE Metrics element has eleven attributes as defined in clause 9.5.2 that correspond to the QoE metrics 
listed in clause 8.4.2. Individual metrics, both at session and at media level can be selected via SDP as described 
in clause 8.3.1.1. 

• The sessionID attribute identified the delivery session. This is of the format source_IP_address + ":" + 
FLUTE_TSl/RTP_source_port. 

• The sessionType attribute defines the basic delivery method session type used = "download" II "streaming" II 
"mixed". 

• The serviceld attribute is value and format is taken from the respective userServiceDescription servicelD 
definition. 

• The cUentId attribute is unique identifier for the receiver, [format is FES]. 

• The serverURI attribute value and format is taken from the respective associatedDeliveryProcedureDescription 
serverURI which was selected by the UE for the current report. This attribute expresses the reception report 
server to which the reception report is addressed. 

9.4.7 Reception Report Response Message 

An HTTP response is used as the Reception Report response message. 

The HTTP header shall use a status code of 200 OK to signal successful processing of a Reception Report. Other status 
codes may be used in error cases as defined in RFC 2616 [18]. 

9.5 XML-Schema for Associated Delivery Procedures 
9.5.1 Generic Associated Delivery Procedure Description 

Below is the formal XML syntax of associated delivery procedure description instances. 

<?xml version=" 1.0" encoding="UTF-8 " ?> 

<xs : schema xmlns : xs="http : //www. w3 . org/200 1/XMLSchema" elementFormDef ault=" qualified "> 
<xs : element name= " as sociatedProcedureDe script ion" type="associatedProcedureType" /> 
<xs : complexType name="associatedProcedureType"> 
<xs : sequence> 

<xs : element name="postFileRepair " type="basicProcedureType" minOccurs="0 " 
maxOccurs=" 1 " /> 

<xs : element name="bmFileRepair " type=" bmFileRepairType" minOccurs="0 " maxOccurs=" 1 " /> 
<xs : element name = "post Re ceptionReport " type="reportProcedureType" minOccurs="0 " 
maxOccurs=" 1 " /> 
</xs : sequence> 
</xs : complexType> 

<xs : complexType name="basicProcedureType"> 
<xs : sequence> 

<xs : element name=" serverURI " type="xs : anyURI " minOccurs=" 1 " maxOccurs= "unbounded" /> 
</xs : sequence> 

<xs : attribute name=" wait Time" type="xs : unsignedLong" us e=" optional" /> 
<xs : attribute name="maxBackOf f " type="xs : unsignedLong" us e=" required" /> 
</xs : complexType> 

<xs : complexType name="bmFileRepairType"> 

<xs : attribute name="sessionDescriptionURI " type="xs : anyURI " us e=" required" /> 
</xs : complexType> 

<xs : complexType name="repairProcedureType"> 
<xs : simpleContent> 

<xs : extension base="basicProcedureType"> 

<xs : attribute name="samplePer cent age" type="xs : string" us e=" optional" /> 
<xs : attribute name="f orceTiminglndependence" type="xs : boolean" us e=" optional" /> 
<xs : attribute name=" report Type" type="xs : string" us e=" optional" /> 
</xs :extension> 
</xs : simpleContent> 
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</xs : complexType> 
</xs : schema> 

"report-type" value = "rack" | | "star" | | "star-all" 

9.5.2 Example Associated Delivery Procedure Description Instance 

Below is an example of an associated delivery procedure description for reception reporting. 

<?xml version=" 1 . " encocling="UTF-8 " ?> 

<associatedProcedureDescription xmlns ; xsi = "http ; //www. w3 . org/2 00 l/XMLSchema-instance" 

xsi ; schemaLocation="http ; //www. example . com/mbms-associated-descrition . xsd"> 
<postFileRepair 

of f setTime="5" 
randomTimePeriod="10"> 
<serverURI>http : //mbms repair .operator . umts/ "</serverURI> 
<serverURI>http : //mbmsrepairl .operator . umts/ "</serverURI> 
<serverURI>http ; //mbms repair 2 .operator . umts/ "</serverURI> 
</postFileRepair> 

<bmFileRepair sessionDescriptionURI="http ; //www. example . com/3gpp/mbms/sessionl . sdp" /> 
<postReceptionReport 

of f setTime="5" 
randomtimePeriod=" 10 " 
report Type=" star-all" 
samplePercentage=" 100 " 
f orceTimingIndependence=" " > 
<serverURI>"http : //mbms repair .operator . umts/ "</serverURI> 
</postReceptionReport> 
</associatedProcedureDescription> 

9.5.3 XML Syntax for a Reception Report Request 

Below is the formal XML syntax of reception report request instances. 

<?xml version=" 1.0" encoding="UTF-8 " ?> 

<xs : schema xmlns : xs="http : //www. w3 . org/200 1/XMLSchema" elementFormDef ault=" quail fled" > 
<xs : element name="receptlonReport "> 
<xs : cholce> 

<xs : element name="receptlonAcknowledgement " type="rackType" /> 
<xs : element name="statisticalReport " type=" star Type " /> 
</xs : cholce> 
</xs : element> 
<xs : complexType name="rackType"> 
<xs : sequence> 

<xs : element name="f lleURI " type="xs : anyURI " 
minOccurs="0 " maxOccurs= "unbounded" /> 
</xs : sequence> 
</xs : complexType> 
<xs : complexType name="starType"> 
<xs : simpleContent> 

<xs : element name="f ileURI " type="xs : anyURI " minOccurs="0 " maxOccurs= "unbounded" > 

<xs : attribute name="receptionSuccess" type="xs : boolean" use="optional" /> 
</xs : element> 

<xs : element name="qoeMetrics " type="qoeMetricsType" minOccurs="0 " /> 
<xs : attribute name="sessionId" type="xs : string" us e=" optional" /> 
<xs : attribute name="sessionType" type="xs : string" us e=" optional" /> 
<xs : attribute name=" service Id" type="xs : string" us e=" optional" /> 
<xs : attribute name = " client Id" type = "xs : string" us e = " optional" /> 
<xs : attribute name="serverURI " type="xs : anyURI " us e=" optional" /> 
</xs : simpleContent> 
</xs : complexType> 

<xs : complexType name="qoeMetricsType"> 
<xs : simpleContent> 

<xs : attribute name="totalCorruptlonDuratlon " type="xs : unsignedLong" use=" optional "/> 

<xs : attribute name="numberOf Corrupt lonEvents " type="xs : unsignedLong" use=" optional " /> 

<xs : attribute name="t " type="xs '.boolean " use=" optional " /> 

<xs : attribute name="totalRebufferlngDuratlon " type="xs :Real " use=" optional " /> 

<xs : attribute name="numberOfRebufferingEvents " type="xs : unsignedLong" use=" optional " /> 

<xs '.attribute name=" InltlalBufferlngDuratlon " type="xs iReal " use=" optional " /> 

<xs '.attribute name="totalNumberof Success IvePacket Loss " type="xs : unsignedLong" 

use=" optional " /> 

<xs '.attribute name="numberOf Success IvelyLossEvents " type="xs : unsignedLong" 

use=" optional "/> 

<xs '.attribute name=" framerateDevlatlon " type="xs '.Real " use=" optional " /> 

<xs '.attribute name="totalJltterDuratlon " type="xs '.Real " use=" optional " /> 
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<xs -.attribute name= 
</xs : simpleContent> 
</xs : complexType> 
</xs : complexType> 
</xs : schema> 



"numberOfJltterEvents " type="xs : unsignedLong" 



"optional "/> 



9.5.3.1 



Use of Specific Values 



"sessionType" value = {"download", "streaming", "mixed") 



9.5.3.2 



Example XML for the Reception Report Request 



<?xml version=" 1 . " encocling="UTF-8 " ?> 

<receptionReport 

xmlns : xsi="http : //www. w3 . org/200 1/XMLSchema-instance" 

xsi : schemaLocation="http : //www. example . com/mbmsReceptionReport . xsd"> 



<fileURI>"http 

<fileURI>"http 

<fileURI>"http 

</receptionReport> 



//www. example . com/mbms-f iles/f ilel . 3gp"</f ileURI> 
//www. example . com/mbms-f iles/f ile2 . 3gp"</f ileURI> 
//www. example . com/mbms-f iles/f ile4 . 3gp"</f ileURI> 
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Media codecs and formats 



10.1 General 

The set of media decoders that are supported by the MBMS Client to support a particular media type are defined below. 
Speech, Audio, Video and Timed Text media decoders are relevant for both MBMS Download and Streaming delivery. 
Other media decoders are only relevant for MBMS Download delivery. 



10.2 Speech 



If speech is supported, the AMR decoder [should/shall] be supported for narrow-band speech 3GPP TS 26.071 [48], 
3GPP TS 26.090 [49], 3GPP TS 26.073 [50] and 3GPP TS 26.107 [51]. The AMR wideband speech decoder, 3GPP TS 
26.171 [52], 3GPP TS 26.190 [53], 3GPP TS 26.173 [54] and 3GPP TS 26.204 [55], [should/shall] be supported when 
wideband speech working at 16 kHz sampling frequency is supported. 

10.3 Audio 

If audio is supported, then the following two audio decoders should be supported: 

• Enhanced aacPlus 3GPP TS 26.401 [28], 3GPP TS 26.410 [29] and 3GPP TS 26.41 1 [30]. 

• Extended AMR-WB 3GPP TS 26.290 [24], 3GPP TS 26.304 [25] and 3GPP TS 26.273 [26]. 

Specifically, based on the audio codec selection test results. Extended AMR-WB is strong for the scenarios marked with 
blue. Enhanced aacPlus is strong for the scenarios marked with orange, and both are strong for the scenarios marked 
with green colour in table 1 . 

Table 1 



Content type 
Bit rate 


Music 


Speecli over lUlusic 


Speecli between lUlusic 


Speech 


14 kbps mono 










18 kbps stereo 










24 kbps stereo 










24 kbps mono 










32 kbps stereo 










48 kbps stereo 
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10.4 Synthetic audio 



If synthetic audio is supported, the Scalable Polyphony MIDI (SP-MIDI) content format defined in Scalable Polyphony 
MIDI Specification [56] and the device requirements defined in Scalable Polyphony MIDI Device 5-to-24 Note Profile 
for 3GPP [57] [should/shall] be supported. 

SP-MIDI content is delivered in the structure specified in Standard MIDI Files 1.0 [58], either in format or format 1. 

In addition the Mobile DLS instrument format defined in [59] and the Mobile XMF content format defined in [60] 
should be supported. 

A PSS client supporting Mobile DLS shall meet the minimum device requirements defined in [59] in section 1.3 and the 
requirements for the common part of the synthesizer voice as defined in ISO/IEC 10646-1 [70] in section 1.2.1.2. If 
Mobile DLS is supported, wavetables encoded with the G.7 1 1 A-law codec (wFormatTag value 0x0006, as defined in 
[59]) shall also be supported. The optional group of processing blocks as defined in [59] may be supported. Mobile DLS 
resources are delivered either in the file format defined in ISO/IEC 10646-1 [70], or within Mobile XMF as defined in 
[60]. For Mobile DLS files delivered outside of Mobile XMF, the loading application should unload Mobile DLS 
instruments so that the sound bank required by the SP-MIDI profile [57] is not persistently altered by temporary 
loadings of Mobile DLS files. 

Content that pairs Mobile DLS and SP-MIDI resources is delivered in the structure specified in Mobile XMF [60]. As 
defined in [60], a Mobile XMF file shall contain one SP-MIDI SMF file and no more than one Mobile DLS file. PSS 
clients supporting Mobile XMF must not support any other resource types in the Mobile XMF file. Media handling 
behaviours for the SP-MIDI SMF and Mobile DLS resources contained within Mobile XMF are defined in [60]. 

10.5 Video 

If video is supported, H.264 (AVC) Baseline Profile Level lb decoder (ITU-T Recommendation H.264 [43] and 
ISO/IEC 14496-10/FDAMl: "AVC FideUty Range Extensions" [44]) with constraint_setl_flag=l and without 
requirements on output timing conformance (annex C of ITU-T Recommendation H.264 [43]) should be supported. 

Note that MBMS does not offer dynamic negotiation of media codecs. To ensure the maximum level of interoperability, 
H.264 (AVC) is the only video decoder recommended for MBMS. However, it is to be noted that ITU-T 
Recommendation H.263 profile level 45 decoder (ITU-T Recommendation H.263 [45] and H.263 annex X [46]) shall 
be supported for PSS (3GPP TS 26.234 [47]) and hence may be used for MBMS User Service. 

When H.264 (AVC) is in use in the MBMS streaming delivery method, it is recommended to transmit H.264 (AVC) 
parameter sets within the SDP description of a stream (using sprop-parameter-sets MIME/SDP parameter - ISO/IEC 
14496-10/FDAMl: "AVC Fidelity Range Extensions" [44]), and it is not recommended to transmit parameter sets 
within the RTP stream. Moreover, it is not recommended to reuse any parameter set identifier value that appeared 
previously in the SDP description or in the RTP stream. However, if a sequence parameter set is taken into use or 
updated within the RTP stream, it shall be contained at least in each IDR access unit and each access unit including a 
recovery point SEI message in which the sequence parameter set is used in the decoding process. If a picture parameter 
set is taken into use or updated within the RTP stream, it shall be contained at the latest in the first such access unit in 
each entry sequence that uses the picture parameter set in the decoding process, in which an entry sequence is defined as 
the access units between an IDR access unit or an access unit containing a recovery point SEI message, inclusive, and 
the next access unit, exclusive, in decoding order, which is either an IDR access unit or contains a recovery point SEI 
message. 

There are no requirements on output timing conformance (annex C of ITU-T Recommendation H.264 [43]) for MBMS 
clients. 

The H.264 (AVC) decoder in an MBMS client shall start decoding immediately when it receives data (even if the 
stream does not start with an IDR access unit) or alternatively no later than it receives the next IDR access unit or the 
next recovery point SEI message, whichever is earlier in decoding order. Note that when the interleaved packetization 
mode of H.264 (AVC) is in use, de-interleaving is done normally before starting the decoding process. The decoding 
process for a stream not starting with an IDR access unit shall be the same as for a valid H.264 (AVC) bitstream. 
However, the client shall be aware that such a stream may contain references to pictures not available in the decoded 
picture buffer. 
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10.6 Still images 



If still images are supported, ISO/IEC JPEG [61] together with JFIF [62] decoders [should/shall] be supported. The 
support for ISO/lEC JPEG only applies to the following two modes: 

• baseline DCT, non-differential, Huffman coding, as defined in table B.l, symbol 'SOFO' in 
3GPPTS 26.273 [26]; 

• progressive DCT, non-differential, Huffman coding, as defined in table B.l, symbol 'SOF2' 
3GPPTS 26.273 [26]. 

10.7 Bitmap graphics 

If bitmap graphics is supported, the following bitmap graphics decoders [should/shall] be supported: 

• GIF87a, [63]; 

• GIF89a, [64]; 

• PNG, [65]. 

10.8 Vector graphics 

If vector graphics is supported, SVG Tiny 1.2 [66], [67] and ECMAScript [68] [should/shall] be supported. 

NOTE 1: The compression format for SVG content is GZIP [42], in accordance with the SVG specification [66]. 

NOTE 2 Content creators of SVG Tiny 1.2 are strongly recommended to follow the content creation guidelines 
provided in annex L of 3GPP TS 26.234 [47]. 

NOTE 3: If SVG Tiny 1.2 will not be published within a reasonable timeframe, the decision to adopt SVG Tiny 1.2 
in favour of SVG Tiny 1.1 may be reconsidered. 

10.9 Text 

The text decoder is intended to enable formatted text in a SMIL presentation. 
If text is supported, a MEMS client [should/shall] support 

• text formatted according to XHTML Mobile Profile [69]; 

• rendering a SMIL presentation where text is referenced with the SMIL 2.0 "text" element together with the 
SMIL 2.0 "src" attribute. 

If text is supported, the following character coding formats [should/shall] be supported: 

• UTF-8, [71]; 

• UCS-2, [70]. 

NOTE: Since both SMIL and XHTML are XML based languages it would be possible to define a SMIL plus 
XHTML profile. In contrast to the presently defined SMIL Language Profile that only contain SMIL 
modules, such a profile would also contain XHTML modules. No combined SMIL and XHTML profile is 
specified for MBMS. Rendering of such documents is out of the scope of the present document. 
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10.10 Timed text 

If timed text is supported, MBMS clients [should/shall] support 3GPP TS 26.245 [72]. Timed text may be transported 
over RTP or downloaded contained in 3GP files using Basic profile. 

NOTE: When a MBMS client supports timed text it needs to be able to receive and parse 3GP files containing the 
text streams. This does not imply a requirement on MBMS clients to be able to render other continuous 
media types contained in 3GP files, e.g. AMR, if such media types are included in a presentation together 
with timed text. Audio and video are instead streamed to the client using RTP. 

10.11 3GPP file format 

An MBMS client shall support the Basic profile and the Extended presentation profile of the 3GPP file format 

3GPPTS 26.244 [32]. 
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Annex A (normative): 
FLUTE Support Requirements 



This clause provides a table representation of the requirement levels for different features in FLUTE. Table A. 1 
includes requirements for an MBMS client and an MBMS server for FLUTE support as well as the requirements for a 
FLUTE client and a FLUTE server according to the FLUTE protocol (RFC 3926 [9]). The terms used in table A. 1 are 
described underneath. 

Table A.1 : Overview of the FLUTE support requirements in IVIBMS servers and clients 





FLUTE Client 

support requirement 

as per [9] 


MBMS FLUTE Client 

support requirement 

as per present 

document 


FLUTE Server use 

requirement as per 

[9] 


MBMS FLUTE Server 

use requirement as 

per present 

document 


FLUTE Blocking 
Algorithm 


Required 


Required 


Strongly 
recommended 


Required 


Symbol Encoding 
Algoritlim 


Compact No-Code 
algorithm required. 

Other FEC building 

blocks are undefined 

optional plug-ins. 


Compact No-Code 
algorithm required. 

[TBD] 


Compact No-Code 

algorithm is the default 

option. 

Other FEC building 

blocks are undefined 

optional plug-ins. 


Compact No-Code 

algorithm is the default 

option. 

[TBD] 


Congestion Control 
Building Block (CCBB) 
/ Algoritlim 


Congestion Control 

building blocks 

undefined. 


Single channel 
support required 


Single channel without 

additional CCBB given 

for the controlled 

network scenario. 


Single channel 
support required 


Content Encoding for 
FDT Instances 


Optional 


Not applicable 


Optional 


Not applicable 


A flag active (fieader) 


Required 


Required 


Optional 


Optional 


B flag active (header) 


Required 


Required 


Optional 


Optional 


T flag active and SCI 
field (header) 


Optional 


Optional 


Optional 


Optional 


R flag active and ERT 
field (header) 


Optional 


Optional 


Optional 


Optional 


Content-Location 
attribute (FDT) 


Required 


Required 


Required 


Required 


TOI (FDT) 


Required 


Required 


Required 


Required 


FDT Expires attribute 
(FDT) 


Required 


Required 


Required 


Required 


Complete attribute 
(FDT) 


Required 


Required 


Optional 


Optional 


FEC-OTI-Maximum- 
Source-Block-Length 


Required 


Required 


Required 


Required 


FEC-OTI-Encoding- 
Symbol-Length 


Required 


Required 


Required 


Required 


FEC-OTI-Max- 

Number-of-Encoding- 

Symbols. 


Required 


Required 


Required 


Required 


FEC-OTI-FEC- 
Instance-ID 


Required 


[TBD] 


Required 


[TBD] 



The following are descriptions of the above terms: 

• Blocking algorithm: The blocking algorithms is used for the fragmentation of files. It calculates the source 
blocks from the source files. 

• Symbol Encoding algorithm: The symbol encoding algorithm is used for the fragmentation of files. It 
calculates encoding symbols from source blocks for Compact No-Code FEC. It may also be used for other FEC 
schemes. 
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Congestion Control Building Block: A building block used to limit congestion by using congestion feedback, 
rate regulation and receiver controls (RFC 3048 [17]). 

Content Encoding for FDT Instances: FDT Instance may be content encoded for more efficient transport, 
e.g. using ZLIB. 

A flag: The Close Session flag for indicating the end of a session to the receiver in the ALC/LCT header. 

B flag: The Close Object flag is for indicating the end of an object to the receiver in the ALC/LCT header. 

T flag: The T flag is used to indicate the use of the optional "Sender Current Time (SCT)" field (when T=l) in 
the ALC/LCT header. 

R flag: The R flag is used to indicate the use of the optional "Expected Residual Time (ERT) field in the 
ALC/LCT header. 

Content Location attribute: This attribute provides a URI for the location where a certain piece of content (or 
file) being transmitted in a FLUTE session is located. 

Transport Object Identifier (TOI): The TOI uniquely identifies the object within the session from which the 
data in the packet was generated. 

FDT Expires attribute: Indicates to the receiver the time until which the information in the FDT is valid. 

Complete attribute: This may be used to signal that the given FDT Instance is the last FDT Instance to be 
expected on this file delivery session. 

FEC-OTI-Maximum-Source-Block-Length: This parameter indicates the maximum number of source 
symbols per source block. 

FEC-OTI-Encoding-Symbol-Length: This parameter indicates the length of the Encoding Symbol in bytes. 

FEC-OTI-Max-Number-of-Encoding-Symbols: This parameter indicates the maximum number of Encoding 
Symbols that can be generated for a source block. 

FEC-OTI-FEC-Instance-ID: This field is used to indicate the EEC Instance ID, if a FEC scheme is used. 
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Annex B (normative): 

FEC encoder and decoder specification 

NOTE: This annex will provide the detailed encoder and decoder FEC specification when FEC code selection is 
complete. Only Raptor codes and/or 2D-Reed-Solomon codes are considered. 
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Annex C (informative): 
lANA registration 

This annex provides the required lANA registration. 



C.1 Registration of media type "audio, video, or 
text/rtp-mbms-fec-repair" 

This media type represents the RTP payload format defined in clause 8.2.1.4. 
Type name: 

• application. 
Subtype name: 

• rtp-mbms -fee-repair. 
Required parameters: 

• FEID: The FEC Encoding ID used in this instantiation. Expressed either as an integer or a string without white 
space. 

• min-buffer-time: This FEC buffering attribute specifies the minimum RTP receiver buffer time (delay) needed to 
ensure that FEC repair has time to happen regardless of the FEC source block of the stream from which the 
reception starts. The value is in milliseconds and represents the wallclock time between the reception of the first 
FEC source or repair packet of a FEC source block, whichever is earlier in transmission order, and the wallclock 
time when media decoding can safely start. 

Optional parameters: 

• FIID: The FEC Instance ID used in this instantiation. Expressed either as an integer or a string without white 
space. Parameter shall be present for all FEC encoding IDs that are not fully specified. 

• FOTI: The additional FEC object transmission information if any that the FEC instantiation uses as defined by 
the FEID and FIID. The content is expected to be binary data but is not necessarily so, however it shall always 
be BASE64 encoded in the parameter value. 

• buf-size: This FEC buffering attribute specifies the actual memory requirement for the size of the hypothetical 
FEC decoding buffer that is sufficient for correct reception of the stream. The parameter can be used for 
optimizing the memory allocation in receivers or specifying buffer size share for the hypothetical FEC decoding 
buffers of different media explicitly. The parameter value is expressed in terms of number of bytes. 

Encoding considerations: 

• The binary parameter FOTI shall be encoded using BASE 64. The RTP payload format is a binary one, however 
as it is restricted to usage over RTP, no special considerations are needed. 

Restrictions on usage: 

• This format is only defined for transfer over RTP RFC 3550 [6]. 
Security considerations: 

• This format carries protection data and instructions used in FEC decoding. Thus alteration or insertion of packets 
can cause wide spread corruption of recovered data. Thus authentication and integrity protection of the format is 
appropriate. See also clause 7 of RFC 3452 [12]. 
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Interoperability considerations: 

• The greatest interoperability issue with this format is that it virtually supports any systematic FEC encoding 
scheme. Thus the issue is to ensure that both sender and receiver are capable of using the same FEC codes. 

Published specification: 

• 3GPP Technical specification 3GPP TS 26.346 (the present document). 
Applications which use this media type: 

• MBMS terminals capable of receiving the MBMS streaming delivery method. 
Additional information: 

• Magic number(s): N/A. 

• File extension(s): N/A. 

• Macintosh File Type Code(s): N/A. 

Person & email address to contact for further information: 

• Magnus Westerlund (magnus.westerlund@ericsson.com). 
Intended usage: 

• COMMON. 
Author: 

• 3GPP SA4. 
Change controller: 

• 3GPP TSG SA. 

C.2 Registration of media type "audio, video, or 
text/rtp-mbms-fec-source" 

This media type represents the RTP payload format defined in clause 8.1.2.4. 
Type name: 

• audio, video or text. 
Subtype name: 

• rtp-mbms-fec-source. 
Required parameters: 

• opt: The original payload type (OPT) of the media that is tagged by this instantiation of the format. This is an 
unsigned integer which range depends on the RTP profile in use, but commonly 0-127. 

• rate: An integer value, equal to the RTP timestamp rate value for the payload type specified by "opt". 

• FEID: The FEC Encoding ID used in this instantiation. Expressed either as an integer or a string without white 
space. 
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Optional parameters: 

• FIID: The FEC Instance ID used in this instantiation. Expressed either as an integer or a string without white 
space. Parameter shall be present for all FEC encoding IDs that are not fully specified. 

• FOTI: The additional FEC object transmission information if any that the FEC instantiation uses as defined by 
the FEID and FIID. The content is expected to be binary data but is not necessarily so, however it shall always 
be BASE64 encoded in the parameter value. 

Encoding considerations: 

• This format is a binary one, however as it is restricted to usage over RTP, no special considerations are needed. 
Restrictions on usage: 

• This type is only defined for transfer over RFC 3550 [6]. 
Security considerations: 

• This format carries source data and instructions used in FEC decoding. Thus alteration or insertion of packets 
can cause wide spread corruption of recovered data. Thus authentication and integrity protection of the format is 
appropriate. See also clause 7 of RFC 3452 [12]. 

Interoperability considerations: 

• The greatest interoperability issue with this format is that it supports any FEC encoding that follows the rules of 
RFC 3452 [12]. Thus the issue is to ensure that both sender and receiver are capable of using the same FEC 
codes. 

Published specification: 

• 3GPP Technical specification 3GPP TS 26.346 (the present document). 
Applications which use this media type: 

• MBMS terminals capable of receiving streaming media. 
Additional information: 

• Magic number(s): N/A. 

• File extension(s): N/A. 

• Macintosh File Type Code(s): N/A. 

Person & email address to contact for further information: 

• Magnus Westerlund (magnus.westerlund@ericsson.com). 
Intended usage: 

• COMMON. 
Author: 

• 3GPP SA4. 
Change controller: 

• 3GPP TSG SA. 
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C.3 Registration of IVIIIVIE type 

"application/simpleSymbolContainer" 

The MIME Type "application/simpleSymbolContainer" denotes that the message body is a simple container of 
encoding symbols for the file repair procedure (clause 9.3.5.2 - File Repair Response Message Format for Carriage of 
Repair Data). 

NOTE: The detailed lANA registration information of this content type is tbd. 

C.4 Registration of IVIIIVIE type "application/mbms-user- 
service-description-parameter" 

The MIME Type "application/mbms-user-service-description-parameter" denotes that the message body is a user 
service description instance (see clause 5.2.4). 

NOTE: The detailed lANA registration information of this content type is tbd. 

C.5 Registration of MIME type 

"application/mbms-envelope" 

The MIME Type "application/mbms-envelope" denotes that the message body is a metadata envelope (see clause 5.2.4). 
NOTE: The detailed lANA registration information of this content type is tbd. 

C.6 Registration of MIME type 

"application/mbms-protection-description" 

The MIME-Type "application/mbms -protection-description" denotes that the message body is an MBMS protection 
description parameter (see clause 5.2.2.3). 

NOTE: The detailed lANA registration information of this content type is tbd. 

C.7 Registration of MIME type 

"application/mbms-associated-procedure-parameter" 

The MIME-Type "application/mbms-associated-procedure-parameter" denotes that the message body contains the 
associated procedure parameters (see clause 9.2). 

NOTE: The detailed lANA registration information of this content type is tbd. 

C.8 Registration of MIME type 

"application/vnd.Sgpp.mbms-msk+xml" 

The MIME-Type "application/vnd.3gpp.mbms-mskH-xmr' denotes that the message body contains the MSK request 
parameters (see 3GPP TS 33.246 [20]). 

NOTE: The detailed lANA registration information of this content type is tbd. 
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C.9 Registration of IVIIIVIE type 

"application/vnd.3gpp.mbms-register+xmr' 

The MIME-Type "application/vnd.3gpp.mbms-register+xml" denotes that the message body contains the MBMS User 
Service Registration parameters (see 3GPP TS 33.246 [20]). 

NOTE: The detailed lANA registration information of this content type is tbd. 

C.10 Registration of IVIIIVIE type 

"application/vnd.3gpp.mbms-deregister+xmr' 

The MIME-Type "appHcation/vnd.3gpp.mbms-deregister+xml" denotes that the message body contains the MBMS 
User Service Deregistration parameters (see 3GPP TS 33.246 [20]). 

NOTE: The detailed lANA registration information of this content type is tbd 
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Annex D (informative): 

RTP packetization guidelines 



This annex provides guidelines for MBMS senders to minimize initial buffering delay between starting of the reception 
and starting of rendering of media data in MBMS receivers: When H.264 (AVC) video is in use, an MBMS sender 
should form FEC source blocks in which the first H.264 (AVC) access unit in decoding order is an IDR access unit. 

MBMS senders should transmit all application data units for a given H.264 (AVC) access unit, or audio frame within 
one FEC source block. 

MBMS senders should set the min-buffer-time MIME/SDP parameter and the minimum buffering delay elements 
included in FEC source blocks to values that are sufficient to cover any required de-interleaving of application data 
units, such as H.264 (AVC) NAL units and coded audio frames, from their transmission order to decoding order. 

When RTP timestamps are converted to the wallclock time of the MBMS receiver, the smallest RTP timestamp among 
the FEC source packets of a FEC source block of a stream should be equal or close to the smallest RTP timestamp 
among the FEC source packets of a FEC source block of any other stream of the same MBMS streaming session. 

When RTP timestamps are converted to the wallclock time of the MBMS receiver, the greatest RTP timestamp among 
the FEC source packets of a FEC source block of a stream should be equal or close to the greatest RTP timestamp 
among the FEC source packets of a FEC source block of any other stream of the same MBMS streaming session. 
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Annex E (informative): 
Change history 
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